In this episode, Chuck, Ayush, and Valentino join Olly Headey as he shares his expansive career journey, from co-founding FreeAgent to navigating the intricate world of cloud migration and technology adoption. They dive deeply into the various challenges and decisions involved in choosing frameworks like React, tackling server costs with CDN solutions, and simplifying complex tech stacks. Olly also discusses his experiences with boot camps, emphasizing the importance of foundational knowledge over trendy frameworks.

They touch on the significance of dependencies in tech projects, the evolving landscape of Ruby usage beyond Rails, and the practicalities of AWS CloudFront integrations. Olly offers his unique insights into balancing established and new technologies, emphasizing a pragmatic approach to tech evolution.

Join them as they explore the nuances of engineering management, the real-world implications of tech choices, and the strategies for maintaining simplicity in a fast-evolving tech landscape. Let’s get started!

Picks

Charles Max Wood [00:00:04]:
Hey, folks. Welcome back to another episode of the Ruby Rogues podcast. This week on our panel, we have Ayush Nwatiya.

Ayush Nwatiya [00:00:12]:
Hello. Hello.

Charles Max Wood [00:00:14]:
We also have Valentino Stoll.

Valentino Stoll [00:00:16]:
Hey, now.

Charles Max Wood [00:00:17]:
Charles Max Wood from Top End Devs, and we have a special guest this week, and that is Ali Hedi.

 Olly Headey [00:00:23]:
Or Hedi, actually.

Charles Max Wood [00:00:25]:
Hedi. No. It's it's fine. I should have asked, but I assumed because I think I'm smart. And then I screw stuff up because I think I'm smart. Anyway, do you wanna just you were mentioning before the show, you've worked at 37 signals. You were the CTO for free agent, which is a, bookkeeping and financial app for businesses. What else is there to know? What else are you famous for?

 Olly Headey [00:00:59]:
I don't I think I think you've you've done it really well for the start of my famous. I don't think so, but, they're they're the 2 main things, really. I mean, FreeAgent, you know, consumed 15 years of my life. So, you know, that that's pretty much most most things. Before that, I was a a software developer, you know, nothing out of the ordinary. Start, you know, started in the nineties. Used to do computer games originally, when they came on CDs and had sprites, that kinda game. And then You built some.

 Olly Headey [00:01:35]:
Yeah. I was a that was my first job. I was just a programmer writing c, c plus plus, and, yeah, making characters move on the screen. So that that was kind of interesting, although quite hard work, I have to say. I wouldn't know. If if if you just want a 9 to 5, I wouldn't recommend video games. My son has

Charles Max Wood [00:02:01]:
to be a video game developer. So

 Olly Headey [00:02:03]:
Yeah. I mean, great great fun. I mean, to to be honest, probably quite different in the nineties. I I have no idea what it's like today. I I'm not really Yeah. In there. But but yeah. And then, you know, doing a variety of different jobs, and ended up being a being a kind of consultant, you know, going into banks, kind of soul destroying, that kind of thing.

 Olly Headey [00:02:27]:
And then, yeah, and and then we had it's funny because we had I had this accountant, to do my, you know, to do my books. I had a limited company, and he used to send a spreadsheet every month and say, fill this in. You know? So I had okay. And so I had to fill in all the bank transactions manually and then all the expenses and then send it back over, and then and then he would do whatever he did and then said, well, you owe this much tax. Pay it here. Okay. So I had no idea about how finance about the finances, how it all worked or anything. It just felt like a bit of a waste of time and and not you know? So as it turned out, Ed, who is another cofounder, a free agent he had.

 Olly Headey [00:03:12]:
He had the state of the captain, and and he'd been you know, he'd started work on this prototype of free agent, using Ruby, because that was super cool. Right? 2006. That was the real tech. And I met and I met Ed and, you know, we kinda got talking, found this connection with our accountant, and he was a bit like, well, do you do you wanna kinda help me build it? I was like, okay. And then quit my job, and that was that. So that's kinda how it came about. And, yeah, 15 years later, I kind of I left because we because we we did an IPO in 2016 on the London Stock Exchange, and then and then we actually got acquired by a bank, in 2018. And so I kind of stayed there for for a little while after that, but then, yeah, left in 2022.

 Olly Headey [00:04:03]:
So that was the kind of the big startup journey of free agent. And rails all the way, Ruby and rails, that was pretty much everything. The whole the whole app, Pretty much. Not not quite, but pretty much.

Valentino Stoll [00:04:16]:
Was it hard to let it go?

 Olly Headey [00:04:18]:
Let it go. Well, I mean, yeah. Yes and no. I think, yes and no. It's that it gives you that sense of identity, you know, and and so you sort of lose this whole thing. It's like, yeah. I'm the cofounder and see. We well, you can always say cofounder of comedy, but, you know, you can't really you you detach from it then.

 Olly Headey [00:04:39]:
But then but then not really because, you know, I think it's for for me, I I felt like we'd almost built everything in it. Like, every feature was kinda done in my mind. Like, it did everything from, like, time tracking all the way through to kind of filing your tax returns, automatically. But at that point, it's like we kinda, you know, it's not like it's kinda done. That's what we set out to do back in the day and, you know, thought we'd never get there, but we did. And and yeah. And the last thing we did was this massive migration of the infrastructure to to to the cloud. Not not none of this cool.

 Olly Headey [00:05:16]:
We move out of the cloud. We'd run the whole thing on servers, our own servers for years. And then in 2020, we did we did that. We moved to the cloud, and that was a big thing. And, you know, for us was a good thing. Yeah. So once that was done, I was like, Yeah, I think I'm think I'm kinda done here. But I do miss it.

 Olly Headey [00:05:38]:
I still use it as well because I haven't I do my own kind of consulting thing now and again, and so I'm still used to it. I'm in there quite often. It's good.

Ayush Nwatiya [00:05:46]:
Yeah. I am a customer and, I just love it because I'm completely technical. This bookkeeping accounting stuff is just so alien to me, and I can just click around and learn stuff from from free agents. So it's, it's been, it's been a boon for me as a freelancer to have that. So, like, what was the motivation behind going to the cloud? Because, obviously, with 37 signals, all the rage is going the other way.

 Olly Headey [00:06:15]:
Yeah. Absolutely.

Charles Max Wood [00:06:17]:
DHH made Kamal so that he could get off the cloud.

 Olly Headey [00:06:21]:
Yeah. It it it is a good question. So, I mean, I guess for a start, I am a big fan of of running their own hardware in in many ways because, you know, that that's what we started doing. It was kind of the only option back in 2006, 2007. I mean, you know, we just rented a server from Rackspace, and that was kind of that. And then, you know, and then we did use there were all these cloud e t two sort of existed, but, early days, you know, it wasn't much tooling around that. And there were things like flight host and these other cloud bright box, a few of these things that we did play around with just the staging servers playing around, but but the actual app run on it run its own hardware. And we did at at one point, Rackspace had a cloud.

 Olly Headey [00:07:10]:
And because we're Rackspace, we were like, no. Let's let's use that. This would be great. And but we we found it really flaky. It was pretty unreliable for us, and we lost a bit of trust. And then, you know, one of the guys, that we had on the team was was just great at building servers and and stuff, networking and whatnot. So we just decided, well, let's just let's just do it. And we just, we just bought some hardware and rack racks it up and did all that.

 Olly Headey [00:07:41]:
And that's how it ran for, well, what would that be about 9 years? But I suppose one of the big drivers was the tech we were using, was kinda niche. We we we were using towards the end, smart OS, which you may or may not heard of. I I don't not many people have heard of it. So it's which is basically, like, ultimately, it's Solaris, but it's an a loom Lumos. And we were using Triton to do, containerization and all of this, but it wasn't Docker. It wasn't Linux. It it was it's kinda niche. Works really well, but actually, the ops team, we'd struggle to hire people to do it for that reason and and also didn't necessarily want to do it, as well, most people.

 Olly Headey [00:08:32]:
So it was it was a little bit troublesome. And, obviously, the cloud had come a long way, which we were already using. We already were using s 3, like, all all the receipts, everything that you can upload to create, it's all in s 3. And that was always the case because, you know, you don't wanna be getting into object storage yourself, really. And we'd already we were starting to do some data science stuff in AWS, and so, you know, a lot of that stuff, it it kinda made sense to us. I'm well, let's just think about moving the app over how, you know, how hard can that be. And there are lots of advantages. And because we've been bought by a bank, they they were, they were kind of big on on the cloud as well, and they also had quite a lot of leverage with AWS in terms of, like, costs and stuff.

 Olly Headey [00:09:19]:
So we could kind of piggyback on some of that. So all of that coming together, re really helped. And, yeah, it was it is it is a good move for us, I think. I mean, cost wise, very hard to compare. I mean, maybe maybe it's more expensive. I mean, it's it's apples and oranges really when you're trying to compare these costs. But, you know, the ops team, getting into kind of the infrastructure automation, infrastructure code, like, which we already did, but we we were using Poppit and and other technologies that we, you know, kind of moved over to Terraform and, you know, all of this, which was much more people wanted to work with this stuff. Right? It was kind of like reasonably new hot tech that people wanted to do.

 Olly Headey [00:10:03]:
And so, yeah, it was it was actually pretty good move, I think. But I do I do kind of miss the power that you get from your own hardware. It's got, it's got, it is got to be said. To to to these databases on, like, Aurora and you get these kind of I don't even know what they're called, you know, the XXLs or whatever. Crazy prices, really, to be honest. But, you know, as long as you can afford it and it's, you know, it fits within your budget and what you want you're willing to pay in terms of, you know, your margins, then it's fine. But if you're trying to squeak, you know, squeeze margins and prove prove things, then sure. But we were optimising really for a big engineering team.

 Olly Headey [00:10:42]:
We had a 100 plus people, not very big ops team, and we only had about 5 people doing all of that, which is about half the size of 37 signals. To be honest. So, yeah, I think that I don't know if that answer your question, but if a ramble

Ayush Nwatiya [00:10:57]:
Yeah. Yeah. No. That's that's yep. Very, very thorough. And, so, yeah, you you left in 2022, and then, you did you go immediately to 37 signals after that? Yeah.

 Olly Headey [00:11:11]:
It would I mean, I I haven't I didn't intend to do that. It was because I knew I was leaving FreeAgent, and at the time, there were a couple of guys that had worked at FreeAgent that had gone there. They've gone they joined in, like, the summer of that year, 21. And, you know, absolutely in touch with these guys. Really great great programmers. You know, fantastic people. And at the time, they they were looking for, like, a director of engineering. And I think one of these guys said, you know, you should talk to Ollie.

 Olly Headey [00:11:49]:
You know, he's leaving leaving Frazhyr. Maybe he'd be interested. And so it was kind of like a recommendation that that happened. And then, you know, I got the I got a call from David. He said, don't worry about this since, you know, one one thing led to another. And I was like, this sounds pretty cool. And and, because quite a few people from free agent, when I when I then joined, I joined in March 22. By that point, they'd hired about, I think there was 5 people that were programmers and 3 agents, it felt a bit like getting the gang back together again, you know, it was I I thought this would be quite cool, I can go and kind of work with these guys who are amazing and and, you know, get to work with 3.

 Olly Headey [00:12:33]:
That sounds brilliant. And then, yeah.

Ayush Nwatiya [00:12:37]:
It's a good the reason I asked about the timing was because I was curious about did you just help free agent get onto the cloud then switch jobs and help another company get off the cloud?

 Olly Headey [00:12:49]:
Wait. Just I said it does look like that, doesn't it? But, yeah, I think well, my my involvement in the in the cloud exit at 37 signals is is pretty minimal. I mean, to be honest, I I I wasn't involved technically really in in in many things there. It it it was it was very much more of a management leadership role. So, unfortunately, I didn't get get stuck in my side.

Ayush Nwatiya [00:13:15]:
Fair enough. So I'm I'm I'm not saying there's just a blow smoke up your ass, but FreeAgent has one of the best, web UIs of of more modern, software as a service app that I've used. And, I was chatting with some of the free agent guys at at Brighton Ruby a couple of months ago, and I said this to them as well. I'm curious from your point of view as a leader, because you grew the company through the 20 tens. How did you avoid this whole hype cycle of React and stuff? And because because the way I see it, most most web UI is a shit because people use React and shoved it where it has no business being. It's it's a great tool for the right job, but, obviously, I can't I'll I'll I'll avoid the rank right now, but so how did you avoid the hype cycle? Just keep things simple and, as such, like, a very it's got a very snappy UI.

Charles Max Wood [00:14:08]:
Yeah, Ollie. How are you such a genius? Thus forward thinking genius.

 Olly Headey [00:14:14]:
Well, I I'd I'd love to claim that, but let let let's dive into what what the reality on under the hood hood is, shall we? So, I mean, front ends. Right? Like, back in 2007, the the naught, it was all, you know, prototype JS, that kind of thing. Right? The JavaScript

Charles Max Wood [00:14:38]:
Oh, you're going way back.

 Olly Headey [00:14:40]:
That was how it was.

Charles Max Wood [00:14:41]:
That's when I got started.

 Olly Headey [00:14:43]:
Yeah.

Charles Max Wood [00:14:43]:
It was prototype. And then jQuery was like the dream.

 Olly Headey [00:14:47]:
Yeah. We didn't have jQuery, but until we, I suppose, fortunately, in some way, we just didn't really do that much JavaScript. Like, I think the only places we really had it were populating combo boxes, that kind of thing. You know, when you change one, the the next one populates. A few things like that. So we we kind of avoided it just because well, I I wasn't really very good at JavaScript by doing it. I am very good at JavaScript even now, to be honest. Because I'm just trying to touch on voice as much as I can.

 Olly Headey [00:15:19]:
And then, you know, jQuery, I guess, came along and we we we use some of that, for a while. And I think part of the thing was that free agents scope was really broad. So when it came to dev, that there were so many features that we wanted to do, and it was like everything it was like payroll and, you know, bank, you know, using bank feeds like Yodlee, we have to do back in the day. There's this huge scope of stuff. So like faffing around and rewriting UIs was not really a useful business thing to do. So we just kinda didn't do it. We just left it. Now except that what what what are the most kind of interactive parts of the app is the banking area where you have all your bank transactions and you kinda click and you can explain them and categorise them.

 Olly Headey [00:16:13]:
Now that probably 20 trying to think 13 or something like that. I think someone had, started playing around with with with a JavaScript framework. I can't remember off the top of my head, actually, what that was called. It was a it was one of the early ones. And then which I think we actually put live perhaps, but then someone during one of our hack days decided to try and build it in React, the banking section, which kinda works, and they got it they got it working quite quickly in a few days, you know, pre kinda prototyping this thing. And it looked it it was better. It works better from a UI point of view, but then what it kinda grew arms and legs. And what happened with that project is that ultimately that area then became written in React and it stuck even though, it was it was much more complicated.

 Olly Headey [00:17:15]:
It's quite buggy, because, like, all the validation for for, you know, was in was on the server side. So all the front end annotation was being duplicated again, including we had stuff like formatting numbers and stuff that the rails app would do. And so when this section got built in React, then all of that had to be people were duplicating number formatting on it. So it's all a bit of it's a bit of a mess, to be honest. And as far as I know, that is still there. That whole banking area in free agent isn't isn't React at, well, inside the kind of mainframe. There's not so much saying

Charles Max Wood [00:17:53]:
that. Disappointed.

 Olly Headey [00:17:56]:
But but then, honestly, I I I now it could be I could be slightly wrong here because it's going going back a few years, but then so everything else kinda stayed the same. And because the React thing took so long, in my opinion was a bit it's protracted and didn't really result in any kind of great value, then nothing we we kinda made the call like nothing else and we have to forget about it. We're we're just gonna leave it as it is and gradually improve things by which point turbo and stimulus was coming along. And by the time I left, then it was like, right, the the future should be in turbo. We'll just stick with the rails convention and we'll do stuff that way. Ideally, maybe replacing the whole react thing at some point. But again, it's it's the same problem like, well, there's lots of other things to do. What that kind of works might as well leave it even though you are juggling different, technologies.

 Olly Headey [00:18:49]:
So it's you know, we we did through general ignorance. We we didn't, you know, rebuild the entire UI in React. So I'm quite thankful that we didn't. I think that would have probably been a bad idea. We did we did have the the mobile apps as, using kind of I don't think we use React Native, but I think we talked about doing that. We we ultimately just went with Native. But yeah. So it it it's because of the size of reagent, there's a lot of different tech going on.

 Olly Headey [00:19:20]:
We did I think we did get rid of jQuery altogether eventually. But certainly even at Basecamp, I think Basecamp still has jQuery in parts. Pretty sure. Could be right. Pretty sure it did as well, you know, because these things are quite hard to extract. It's it's a lot of effort and and for pretty much zero user benefit, pretty much. And it they kind of work. Right? So, it's it's tricky managing things on on that scale, I think.

Ayush Nwatiya [00:19:49]:
Yeah. I I've never understood this whole thing of rewriting stuff that does the exact same thing, but in a new stack. I'm like, what's the point? It just it just wasted effort. So, yeah, if it works, just leave it. Let it work.

Charles Max Wood [00:20:03]:
I I generally agree, but if the ongoing maintenance burden will be lessened by rewriting it, and it's not, like, a total, hey, you're gonna spend 6 months rewriting this piece. Right? So you have to weigh all these things, but the I've I've worked on apps where there was a new better way of doing things. It was not terribly onerous to change it over. Yeah. There was no real benefit to the users except that the next time we had to come along and maintain, touch, modify, whatever that application stuff, it was going to be much, much, much easier. And so it allows us to deliver better and faster in the future.

Valentino Stoll [00:20:48]:
I feel like too, you know, like, a a lot of people don't like, they like to draw parallels of, like, front end coding to back end coding. And, like, you know, if somebody wants to switch to Rust, like, you know, that's a much steeper learning curve than just switching from jQuery to React or something like that.

 Olly Headey [00:21:10]:
Yeah. But, I mean, I guess what's tricky as well is when when you have a a lot of engineers, you know, dozens and dozens of engineers, you get a lot a lot of opinions as to what is the right thing thing to do. And even when, you know, you're talking about, well, let's do stim we'll do stimulus. That's how we're gonna do these things. You know, then you're gonna people are gonna say, well, great. Can we use stimulus reflex? Can we do that? Because here's a good reason to to to use this or, you know, it's a challenge to kind of try and create standards, which you ideally would like because then everything's the same. It's a level playing field. You you all know what you're working on.

 Olly Headey [00:21:51]:
But in in reality, it's like, if someone thinks they can do that and there's a benefit to doing that, is is it bad? Is that dangerous? Are you gonna end up in that situation where you're you're just using an obsolete technology that you have to then replace or actually is it fine? It's you're kinda making bets regardless of what you do. And sometimes, you know, the stimulus is good, isn't it? But it well, in my experience, which is isn't huge to be fair, I think it it's quite opaque in terms, like, exactly how to how what is the best practice like for an infinite scroll? I I don't know. Like, if you Google it, there's, like, loads of ways of doing it. Is which way should I do it? And not a contrived example, maybe, but there's that that kind of thing where it's where it's kind of, in my opinion, quite vague, documentation about how to do stuff. You you are kind of left to googling or chat GPT and hoping it comes back with stuff where, and it's the same in the business. It's like, well, only stimulus reflex is that bad. I'm just gonna include this particular JavaScript stuff and it's gonna fit our needs here. Is that bad or is that good? I I kind of think it's okay, but I'll kind of keep an eye on it.

 Olly Headey [00:23:07]:
Whereas with React, that's very much it's a different paradigm, isn't it? That that's much more complicated, I think. Whereas, just JavaScript libraries. Yeah.

Valentino Stoll [00:23:18]:
So how do you assess, like, switching to new technologies or adopting new things? Like, what is your thought process on, like, doing that?

 Olly Headey [00:23:28]:
I think my default is is always, well, why do we need to change anything? Can we just not? Because changing stuff is just like work, and it's gonna take longer than anyone says it will. And so can we do you know, can we just not? And and there are people on there that still build stuff with jQuery and stuff because it just it works. It's not bad. It who's that guy on in on x who's, like, the millionaire hacker guy, the Nomad List guy, the levels, Peter levels. And then he he he builds all of his stuff in PHP and jQuery, isn't he? Like, he can he can build anything with with this stuff. So, I think if you can resist but then when you say you're resisting change, then you can you're kind of like an old dinosaur, aren't you? You don't wanna change. But the reality is this when you're running a business, you just you you do have to kind of focus mainly on customer value. And if it's not gonna bring that value or maybe, like, increase their velocity by an order of magnitude or something, then do you do you really need to? Or or is there if you are gonna do it, then how can you do it incrementally? You know, how are you gonna do that? And it's like, if you wanna go back to, you know, turn everything into stimulus, that's great.

 Olly Headey [00:24:52]:
Don't do the big stimulus projects that's just gonna take 18 months bit by bit. You know, like, we're we're gonna work on this banking area. Let's just tackle that one while we're while we're in there. That that that's more of the approach I I would really take, I think. Resist as long as possible until it became glaringly obvious that either everyone's gonna walk out, which is, you know, not with our cloud stuff, you know, I don't I don't think people are going to work work out. But I think if we really tried to keep forcing kind of smart OS, try to turn down everyone's throat, I don't think we really ended well. We were gonna we had to do something there. But from a programming point of view, I'm not sure how common common that that problem is really.

 Olly Headey [00:25:39]:
But you do tackle hard ones, you know, like a Ruby upgrade. What's good about things like that is that, you know, you get the obsolescence. So you you know that if if you don't fix stuff by this date, then you're unsupported and you're you're you're in dangerous territory at that point. So that's quite nice when you have these actual debts. So if someone said about jQuery is getting turned off, not you. You can't really do that for me, but if they did, then maybe that would be a good a good thing to do. But yeah. But to try and simplify it as well, though, because that that's always the challenge to try and keep the stack and and everything as simple as you can, which is which is hard.

 Olly Headey [00:26:22]:
And it's something that 37 signals obviously do really well, but then they have fewer moving parts, I think, you know, and and they invent all that stuff anyway, so it's kinda different.

Ayush Nwatiya [00:26:36]:
Yeah. The simplicity the simplicity side of things is is huge for me, and I also have, like, I have a, an allergy for dependencies. I hate pulling in dependencies. I just, like, I will need to have a really, really good reason before I add something to my gem file. Like, it'll be, like, literally, like, I do not want to solve this problem by myself, and that's when I'll pull in a gem. Because I think most of the time, you could just spend 2 or 3 hours and build something yourself that specifically solves your problem, and it'll save you so much time in the long run because you don't have an external dependency that you don't control.

 Olly Headey [00:27:15]:
Honestly, that is such good advice. I think yeah. I we we maybe didn't heed that. You know, there there's always this tension, isn't it? A bit you know? Well, it's it's a bit like a build versus buying, although it's open source. You're not really buying. You're just kinda borrowing. But, yeah, when you come to do a rails upgrade and, you know, that those that one gem that you use for, like, tagging or what whatever it is, there's some gem, and it's just like, oh, shit. That that is unsupported for rails 6 or 8.

 Olly Headey [00:27:44]:
You think well, but if you wrote your own, it's probably like a couple of classes and it is not very complicated. You could do that yourself. And that's something, you know, 37 signals do so well. Their gem files are pretty small, really. Whereas pretty sure, pretty large. And it's definitely something I'm take I've taken on board a lot. I think that it is quite it's good practice to try and minimize as much as possible. I do remember 37 signals when when they were starting on, I guess it was the calendar app, and I think, you know, David's looking at the these gem piles and basically, well, what what why if we got red Redis? Why why is Redis in there? And it ultimately led to kind of the solid cache and and solid queue stuff, which is just like, hang on.

 Olly Headey [00:28:33]:
Database is really fast. Why why would you don't need Redis? That's just a thing we just don't need, and it's a thing we have to support, which ended up it's funny. That ended up leading to the to these gems being built. Like, I'm sure they're fast enough. You know, database is the fastest now on these new drives. We just bought we don't need rest. And and it it's almost like I I don't know what this is. What was it, David? It was always like that.

 Olly Headey [00:28:52]:
It was literally that dependency that was so irritating. They will just go and build all this new tech just because that is, you know, 1st grade. Right? Because you've got one less dependency, although have you? Because you've now got these highly complex gems, to maintain, but I don't know. Whereas Redis is pretty reliable, to be honest.

Valentino Stoll [00:29:12]:
I'm curious on your thoughts about this idea because, like, I when I I'm I have a total agreement, like, let fewer dependencies, the better. But at the same time, like, some dependencies are, like, it's better to have a community building and identifying bugs and resolving features. Like, what are your thoughts on that? Like, how do you gauge, like, whether or not, like, community support around a certain feature set or technology or or gem is, like, worth it, over building it yourself?

 Olly Headey [00:29:41]:
Yeah. And and I mean, for start, I suppose you have to have to look at the activity on it. Don't you? If if it's an active gem, then and pretty entrenched in, you know, in in in the community, then that that's always a good sign. I I don't think I would I would hesitate really to to use the gem in in that case, unless as as I say, it was so simple that you just think, well, do I really need to do that? You know? Because sometimes they can complicate things and sometimes not. But the hard I suppose the harder the problem that you're trying to solve by using that gem, then the more likely I I would say it's probably better to use a gem, at least in the first instance. Right? And and if it if for some reason it gets unsupported or causes you, I don't know, performance problem or something, then then maybe maybe do it then. But if if your goal is to move fast and just get stuff done, then, you know, bring in device. Right? Look.

 Olly Headey [00:30:40]:
Most people do that. I don't know. Whereas, you know, I I built a couple of little apps recently, and I I'm not gonna use device. I can do that myself. And I ended up doing my own auth, which for better or worse, you know, it didn't take that long, but at the same time, you know, it would have been much quicker to to use device. But, you know, I just I don't know. I don't know why. But then I've had the same problem with apps where I've used device, and then I've I've wanted to kind of rip it out because it was too painful to go into just that template of some password.

 Olly Headey [00:31:17]:
I can't even remember the examples, but, you know, some sort of it shouldn't be that hard. And I found there were certain things that I found hard. I'd rather just do my own kind of confirmation email sometimes, but then I guess it's also a balance of what is it's what time you have available, what you kind of skill level is at some level, I suppose. If you really don't wanna get into that, then why why bother? If you're if you're building a product, you know, like, for agent or something that's a certain signal to maybe just kinda you do wanna own that yourself just in case device stops or if it it, you know, deviates from what you need or if you end you wanna customize it, then maybe it's just a bit too hard, that kind of thing. But again, I I you know, another app I'm I built, like Google Auth, which I thought was gonna be straight straightforward, but that's my own, naivety showing that, you know, when but then I tried OmniAuth and that was there were certain things. It was slightly out of date. It's a little bit bit fiddly. So I think if you're a business and you're well funded, you're making money.

 Olly Headey [00:32:23]:
Yeah. I don't know. But if you're a business, you're making lot you're making money or you're well funded, then, you know, maybe you should build your own if it's not gonna be too onerous to do that because then you own that tech and you can support it without question. But if you if you're in the early days or if you don't have that, you know, capacity, just use the gem and and hope for the best. But these things change. It's like active storage. You know, we we used, well, originally, a fridge. Like, I think it was paper clip or something.

 Olly Headey [00:32:52]:
Pretty good. Mhmm. And I think it's, I can't remember. I think didn't it get it got support stopped, but it's then we moved to shrine. And then I think active storage appeared, but then I think we left it on shrine. But then that now it's like, you're using this unusual even though arguably shrine is better, it's like most people don't know it. They'd rather use active storage. Like but, well, I'm glad we didn't build our own one of those to be to be honest.

 Olly Headey [00:33:19]:
I think managing storage upload would probably have not been a great idea. I'd rather migrate from one thing to the at that point.

Valentino Stoll [00:33:27]:
At least you're not someone like thoughtbot that has, like, all of their clients using their thing and but they now have abandoned. And and they now have to upgrade everybody and and worry about that. But I'm curious, like so let's take a take a look at the dependency, like, aspect of things. Like, do you ever look at Rails as, like, do I need Rails, like, kind of thing? Because one thing I, I've been to a lot of, like, you know, non US based or European based Ruby Conferences. It's, like, very much, like, absent in those community rails. It's, like, not kind of, like, the preferred choice. And so, like

 Olly Headey [00:34:05]:
As a web framework, what do you mean they're using? What, like Yeah.

Valentino Stoll [00:34:09]:
For, like, you know, just the the Nantra or, like, you know, some other web framework or just, like, Ruby specific app. Like, they're just running Ruby itself. Like, do you ever, like, think about whether or not, like, you need, you know, rails for something that you're building? Like, can this work as a spreadsheet, or, like, is this better as a command line tool? Like, do you ever look to other things, or is it just, like, default at this point?

 Olly Headey [00:34:36]:
I mean,

Ayush Nwatiya [00:34:36]:
it's a good question,

 Olly Headey [00:34:37]:
but I I suppose, yeah, it depends what the problem the problem is. I mean, for for a web app, I I'm just using rails. I mean, you could say, well, there's quite a lot of baggage, isn't there? You know? Right? But it's it's there. Yeah. Sure. You can write in a Sinatra app in a few files, but then a rails a rails app, you're only really populating a few files. You're like your roots. Maybe you've got a controller.

 Olly Headey [00:35:02]:
But at least it's pretty easy to find your way around. It's not true. Maybe maybe not. An active record is, like, baked in and sure I can pull in active record or I I don't know why I would bother doing that. I mean, may maybe there's, like, an overhead in, like, memory or something. I don't really know. Maybe there's a thing there. Who knows? But personally, I would just use Rails.

 Olly Headey [00:35:22]:
But yeah. Yeah. Command line apps, we would, you know, not use Rails for that. I mean, but it it depends, like, a phrase in one of the one of the one of one of the main things it it does is, like, PDF of invoices. You know? And it lets you can download PDF, attach it to an email, all of that. And that so that's the kind of thing that we wouldn't do in Rails because well, I think it it's not quite straight it's not straightforward. It's so we so we, like, had a Java thing that generated that, but Rails would call it. So, you know, it was in the Rails app that was kind of talking just to an API to to generate this this PDF.

 Olly Headey [00:36:03]:
So that kind of thing, we wouldn't, you know, be fundamentalist and go, it has to be in Ruby, has to be in has to be in Rails, but, just when when there's a best thing for the job, you would you would do use that if it's not too objectionable. But, honestly, in Rails, I I don't know why they're they're not talking at conferences that that much about it. I I mean, I suppose what is that well, not you have Rails world now. Right? So that's gonna be all about Rails. So so maybe the other conferences have won a bit less of that. And it is interesting to hear different stories of what people are doing with Ruby that doesn't include Rails. I mean, you know, if you're working on a SaaS app, that's kind of, a big part of it. But then, you know, that people are doing, like, date data stuff with Ruby on these days.

 Olly Headey [00:36:52]:
I mean, I know Python is, like, the the go to kind of language for that kind of stuff, but there are people trying to do stuff in Ruby, which I think is pretty cool. But but I'm not yeah. I I wouldn't be fundamentalist about it, but if I was building a web app, I would just use Rails. Just works. Right? Isn't it? It's great.

Ayush Nwatiya [00:37:14]:
You're just, pulling on this dependency thread a little bit more like, going back to your authentication example. The I I do my own auth. I don't like device. I don't like pulling in anything to that. But the way I see it, once I've built it once, I can then I know this is blasphemous to some people, but just copy paste the code into other apps and then tweak it as necessary because sometimes you need to just tweak things a little bit for, like, for the use case at hand is. And once you have something working, if you've written it well, that code should be reusable, I think. And, that's something I kinda think about a lot is that trying to maximize the reusability of code that are that's not necessarily in a way that it can be extracted through a library because, it's different when you've got code living in your app and when you're kinda extracting something because then when you put it in the gem, it's more of a black box. But, yeah, copy paste code.

Ayush Nwatiya [00:38:16]:
Once once you solve the problem of authentication on your own, you know everything about how that code works, and you can just copy it into other projects. I know what you think about that kind of approach.

 Olly Headey [00:38:27]:
Yeah. I mean, that's that's kind of I kind of have to know. I suppose on the apps that I built, one used Google auth, so that was slightly different. And then but the but the one one used email authentication and and one was user password, so they're all they're all different for whatever reason. They're they're for because reasons. But but, no, if I was I I would I would probably do the same. I think I mean, Rails has baked into it, doesn't it? You know, that has secure password stuff. It's kind of baked into it now, which is great.

 Olly Headey [00:39:02]:
So it's it's pretty easy to do that. I suppose things like the the forgot password is it that boiler plate of stuff, but it is it's quite small what you you really need to do, kind of validate the email address and forget a password. They're they're the things that I would need to do. But, yeah, like I say, putting that in a gem is would you do that? Because you're making assumptions about models and things. Like, I guess you could do that, and that's what Devise has done. So maybe you should just use Devise at that point. But then Devise is quite big. It always feels quite big to me.

 Olly Headey [00:39:38]:
But, yeah, that I I suppose that's how I do it, but then but also what what about when, you know, because usernames and passwords are unpopular perhaps these days. I mean, what what I see using various apps around around the Internet, you know, is well, 2FA. Right? Like, how are you gonna do that? And also, are you gonna do it with SMS, email, or send, you know, one time passcodes? And there's there doesn't and always are you gonna go with pass keys? Because that isn't a new thing. No. And it's I'm not sure I would do that myself, even 2 FA. You know? I don't know if you've done that your yourself or not. Or maybe I mean, that's maybe something that Rails can will get baked into it at some point maybe if that's the trajectory it's going or pass keys, maybe that'll come. That might be a good thing.

 Olly Headey [00:40:31]:
Kinda surprised it hasn't got rails doesn't have a device built in, to be honest. Feels like

Ayush Nwatiya [00:40:37]:
it should. There's gonna be something in rails. It's some kind of generator, I think, for Right. That gives you a skeleton of authentication. And I think I remember seeing a tweet from DHH, like, a couple of years ago that they might do something, like, similar to has secure password but for, one time pass keys, like, you know, those authenticator app. What's it called? T o t p, I think, the time based ones. Yeah. I think there's some I saw some chatter about, like, a high secure password flavor of that kind of thing.

Ayush Nwatiya [00:41:10]:
I don't think anything's actually gone in, but, yeah, it'd be good to have for sure.

Valentino Stoll [00:41:16]:
Yeah. Dave can have his action off too. That's pretty great.

Charles Max Wood [00:41:21]:
Yeah. Action off is nice. The the thing is is that, you know, kind of what Ayush was talking about, I've I've wanted something more like 0 auth or where, essentially, it is the generator that just sticks the code in. I mean, I've I've looked at the code for action auth. It's it's pretty easy to follow. But, yeah, it still, to me at least, has that feeling of that black box where, you know, the 0 authentication library, it there's no there's no engine. Right? It just sticks the code in, and then you can modify it until to make it whatever you want. And and that's kind of the thing that I really like.

Charles Max Wood [00:42:04]:
And so, I'd I'd love to see a lot of these common problems. In fact, I negotiated with, Daniel Kehoe. I don't know if you guys remember him. But he he had a series of rails apps that he had recorded videos of himself building way back in the day. And, he had a project called Rails Composer, and, essentially, it asked you a bunch of questions and then populate your gem file. And, yeah, that that's my idea behind that. He gave me the domain, and I want to just build a series of of things like this. So it's like, hey.

Charles Max Wood [00:42:42]:
You have this common thing and, yeah, rather than have another gem added to your gem file, you literally have Rails composer in there in your development group, and then you just run the generators. And it generates it and then, kind of has the documentation in line like the Rails stuff does that may point you out to videos that show you how to modify it to be whatever you want it to be. Because I I really and and it's funny because initially I was gonna I was gonna do engines, and then I started reading Ayush Ayush's book, and it walks you through building the authentication. And I'm like, this is just so much cleaner in so many ways, and I can make this into whatever I want. Right? It it gives me the freedom to just do what I need. And so, yeah, I could give you all the pieces. It'll have a nice interface. It'll all be Tailwind or whatever.

Charles Max Wood [00:43:36]:
Right? But then you can just go in and modify it. So if you're using Bootstrap or something else, if you if you need it to do a couple of extra things, if you need to to trigger some jobs. Well, it generated the code. It's in your code. You check it in so you can change it. Anyway

 Olly Headey [00:43:51]:
Yeah.

Charles Max Wood [00:43:52]:
But but I've been very inspired by this idea. Right? Do I need a gem for this or not? Like, I've been using Friendly ID for years, and I figured out that Mhmm. In about in about 30 lines of code, I can create a concern that I can pull into any model I want. Right? And so then it's okay. So why am I using a gem for this? Right? This is code I understand versus code I I could go look at it. I'm sure it's relatively easy to follow along with. But, yeah, then why why do it the other way?

Valentino Stoll [00:44:24]:
Ali, I'm I'm curious, like, you have a lot of experience in, like, product development and, like, the business focus aspect of, like, building things. Right? So I'm curious, like, what your thoughts are on, like, you know, where the technology, like, is most helpful in the process, in the business side of developing the product? And, like, why are you still sticking with Rails at this point with all of the other, stuff that's available? Is it familiarity, or, like, where do you see, like, the technology really aligning with that aspect?

 Olly Headey [00:44:59]:
I mean, I mean, that's a good question. Right? Because well, I I'm I'm not kinda setting up an big SaaS business right right now, but but if I was, would I would I use use rails? I've I mean, me, personally, if I was like a founder founder CTO again, I I probably would, mainly because that's like all I know, and I'm kinda institutionalized in in rails. Right? So there's that. But I still don't think it would be a bad choice. I think it would be a a good choice because, you know, as you know, you can build pretty much anything you need to with rails. Certainly good enough and certainly in the kind of b to b SaaS space, of course, like that, which is, you know but that said, you know, it it depends what what you're building. If if you're, you know, if it's a consumer app, is are you gonna be able to do what you need to do on the front end with with, you know, rails stimulus? Is that is that, you know, good enough or do you do you actually need to lean on the community of of more JavaScript stuff, whether that's React or or Vue or whatever else? I mean, you can still use rails on the back end, but are you then moving into a different architecture driven because of your needs on on the front end? I mean, maybe that would be a different consideration. I I think at one level, I honestly don't think it it really matters because technology isn't it's not usually the thing that kills businesses.

 Olly Headey [00:46:28]:
It's it it honestly doesn't usually matter. Like, the the main problems with businesses are, like, product market fit. Like, you you've built some in and no one wants it or you've marketed it wrong or you can't get the distribution. That's usually the problem. Not not tech. Businesses don't usually fail because someone picked rails or someone picked TypeScript or or whatever. That that doesn't seem to be the a pattern. So I think it really matters.

 Olly Headey [00:46:56]:
But what I do think is interesting so I I do kinda talk to a lot of startups, on some kind of, like, investing and stuff, but, you know, and generally in the startup community, I'm virtually none use rails. But I in fact, maybe none that I spoken to that is. Whereas React's on the front end and something on the back end that is typically node types TypeScript, maybe Python, is the prevalent tech of today, which I find quite do quite find quite fascinating. But these teams move fast, did they get stuff done? They you know, just like we do with rails. So you know, but it's arguably a bit more is it more comfy it feels more complicated to me. But then, you know, at the same time, companies building on cloud tech as well. Right? And they're just leveraging serverless to do a whole manner of cool things, which, you know, there are legit use cases doing that kind of stuff. But at at some level, I don't think it really matters.

 Olly Headey [00:48:05]:
I think Rails is still a brilliant choice. I would do that, but, again, that's because I'm probably institutionalized. But I I wouldn't go learn new tech just so I could build if it unless it was for a specific advantage. You know, if you were doing some kind of AI stuff and you you must use Python, then sure. Do that. Is

Valentino Stoll [00:48:26]:
there an example in Rails where, like, you found that that that feature being there just saved you a ton of, you know, effort if you had gone with something else in the moment?

 Olly Headey [00:48:41]:
It's a good question. I I I was doing some stuff, earlier this year that did kind of touch on it. It was like it was to do with image categorization photographs. Trying to kind of categorize photographs, and I did I mean, I was using APIs to do that, like Microsoft APIs. They didn't support Ruby out of the box. They don't you know, they they have JavaScript. I can't remember. JavaScript, Python, Java, maybe some maybe c sharp, maybe because it's Microsoft.

 Olly Headey [00:49:13]:
I can't remember. But that that those are kind of the libraries, the SDKs that they offer. They don't offer Ruby, which is a shame, but there are there are gems that that kinda wrap this stuff up. And and so that was quite that was quite interesting. But then some of the functionality that I mean, AI is not my not my thing really, but I was kind of toying around with this stuff. And Python does have a wealth of these libraries to do a lot of, kind of machine learning algorithms, which Ruby doesn't really quite have. I mean, I mean, there are people that are creating similar libraries out there for some of this stuff, but it's it always feels, I don't know, not not quite not quite there. So from an AI point of view, depending if you're just calling APIs, of course, fine.

 Olly Headey [00:50:06]:
You can do that from anything. But if you're then trying to do some stuff yourself using it, then it doesn't quite feel like the right choice. But maybe that's changing. I I I it's only superficial knowledge that I I really have of of that. But I I can't really off the top of my head, other other examples. I mean, there was this PDF thing that I mean, that was a very good example where you just couldn't were you gonna do, like, do it with prawn or something where whereas, you know, we we we were using Java libraries that actually did proper PDF, rendering. But, you know, there were there were other ways we could have tackled that, but, we chose the the different tech path as opposed to finding a Ruby a Ruby way to do that. So I'm sure there are lots of other examples, but, you know, I think where rails does seem to to shine is when it's much more of a a what people people call them CRUD apps.

 Olly Headey [00:51:08]:
Don't they? We do, like, kind of it's kind of a bit demeaning. It's like free agent is a CRUD app. Yeah. I guess. It's like, you know, you take some input and you save it to a database, but at the same time, like, come on. There's, like, half a 1000000 lines of code doing lots of stuff, but I guess it's a CRUD app, you could say. Same with, you know, Basecamp as well. CRUD app.

 Olly Headey [00:51:30]:
Then what isn't Notion's a CRUD app, isn't it? I don't know. So, that's come that's a who knows? So CRUD app might be like, hang on. That's that's everything at some level, isn't it? Part of maybe chat GPT or something, but we're not we're not building that.

Ayush Nwatiya [00:51:48]:
Yeah. Most apps are crowd apps. I think it's just, something people don't like saying. My client at the moment is actually, is a start up, and we're completely rails. So there is at least one start up. And I had briefly spoken to another start up a couple of months ago about working with them, and they were gonna be completely rails as well. The way I see it, if it does something that you can't really do in in Ruby or in Rails, it's usually something with quite a small footprint, and you could just extract that into its own service and build it using something else. So, like like the p d PDF thing you said, so, yeah, you can't do that in Ruby.

Ayush Nwatiya [00:52:24]:
Okay? Build that one tiny thing using something else Exactly. And then just call it.

 Olly Headey [00:52:30]:
Yeah. And and I think that's entirely the the right approach. But, yeah, good to hear this, you know, more more startups there. I mean, I I a lot of people building, like, indie hacks, which is kind of like a another kind of really derogatory terms, but actually kind of that's where everything starts in a way. You know, using rails, it's just that, you know, a a lot that I've seen. So, you know, hopefully, we'll kinda see. I think this is where, like, the rails foundation does come into play. You know, there's a lot of money there, and they're doing some cool stuff.

 Olly Headey [00:53:05]:
There's obviously the conferences, and the the guides looking a lot better now. But for me, it's like the outreach and and how how can the Royal Foundation just, get people an earlier stage in their career, I guess, and even boot camps and the rest of it to start using rails? Because boot camps did do rails back in the day, and now they have tended to move from what I understand to more of a kind of a JavaScript ecosystem, which feels I don't know. I mean, to to put yourself in in the place of someone on the boot camp who doesn't know anything about programming and all of a sudden you're, like, having to do, like, React sounds overwhelming to me. Whereas at least with Ruby, it's like kind of here's an ERP template, and it's just basically HTML. That feels a bit a bit less but but maybe more people go through these boot camps and do great, so it could just be my own biases here that are showing. But I think that's gonna be an an important part of Rail's future success is to get in the grounds again and make make people realize that how great it is. And I think, you know, that's part of the job of rails foundation, but get everyone else shouting about it as well, really. So hopefully I'm I'm I'm hopeful that this is, this is already happening and and we'll get better as well as people.

 Olly Headey [00:54:35]:
Because there there was a talk, wasn't there? Was it, Irina from Evil Martians? And she did a talk about, startups on rails or something. I didn't see the talk, but I think I've seen the slides. And, you know, she talks about, some really interesting companies and companies that were built in other tech that are moving back to, like, a rails. We we were all microservices, and now we're gonna come back to a rails monolith because, frankly, it was just chaos. And and now this is far simpler, and we didn't really need all of that complexity and distribution. We just needed an an app with a big database, and that goes a long way usually. So so, hopefully, we'll we'll start to see this change.

Ayush Nwatiya [00:55:19]:
Yeah. I think, Boot Camps have just kinda generally moved away from teaching web fundamentals. Like, it'd be good to just have them go back to teaching literally the basics of web development, HTML, CSS, JavaScript, and obviously, I'm biased with Ruby and Rails. But, because last year, I, I helped out with the Rails world website, because the Rails foundation wanted a junior developer to build it, and they wanted someone to mentor the juniors. I, I have done with the mentoring. And, she was a boot camp graduate. She graduated from Le Wagon quite recently. And, they had a little bit of rails and quite a lot of react in the curriculum if I remember correctly.

Ayush Nwatiya [00:56:03]:
And I remember showing her what you could do with just a custom element in JavaScript, and it was like, woah. This is so easy. And it's like, yeah, I just wish boot camp would teach that kind of stuff a bit more.

 Olly Headey [00:56:15]:
Yeah. And like like you say, you know, teaching JavaScript is super important. You have you have to kind of know JavaScript, but not necessarily a hugely complex level. You know, like you say, little sprinkles of the JavaScript, is is often more than enough, to accomplish what you need to do and certainly at the boot camp level. But but on the other hand, then they're, you know, it's this chicken and egg problem that they're they're trying to get people jobs. That's that's what they're there for. And if and if all the jobs react, then that it's it's their duty to then go and teach people what's gonna get the most likely to get them the job so they can have their, you know, placement stats nice and high. So it's a tricky one.

 Olly Headey [00:57:01]:
You you need the jobs. Otherwise, the boot camps might say, well, this movie surface, but we're just we're not there's no jobs in that, so why would we bother teaching it? And then you're on a bit of a downward spiral. So, yeah, tricky. Yeah.

Ayush Nwatiya [00:57:17]:
It's also adding a little bit of just short term versus long term. Like, yeah, learning React will get you a job in the short term, but then when React goes out of vogue, you won't have that, foundation of basics to kinda fall back on and then learn something else, but that's a different discussion, I think.

 Olly Headey [00:57:36]:
Yeah. I think so. It's pretty entrenched, I would say now. I think pretty much.

Ayush Nwatiya [00:57:39]:
Yeah. That's true.

 Olly Headey [00:57:40]:
It's here to say. Sadly.

Charles Max Wood [00:57:43]:
Well, anything else that we wanna dive into here?

 Olly Headey [00:57:46]:
Which we didn't touch on the old, rails assets. The original, article that that that you got in touch about, I suppose.

Charles Max Wood [00:57:58]:
Yeah. We we should we should definitely do that here for a minute. I I actually am kinda curious about it. So, I have to admit, I haven't read the article. I didn't see that that was well, I'm working on a better system for letting us know what we need to read in order

 Olly Headey [00:58:16]:
to prepare. Yeah. For sure.

Charles Max Wood [00:58:18]:
In the meantime yeah. You know, I I think well, actually, why don't you just give us the 10,000 foot view on what the article's about, and then we can kinda

 Olly Headey [00:58:27]:
attack it. Yeah. Of course. So it it was one of those things where, you know, I was I was ringing that, and I'm I'm I'm lowest to pay anything more than I need to, the absolute minimum amount for a server to run to run this thing on. Right? And, yeah, you you and it's using active storage to store, you you know, uploaded content. But the particular app that I was building, involved customers uploading photos in bulk. So dragging potentially 100, small 100 of photographs into a drop, you know, drop zone thing and and uploading them all and then viewing these things in the app so you can view, you know, 3, 400 photos in a gallery. Of course, there's, like, infinite infinite scroll and so on, but this is quite a lot of requests on the app when your images, you know, are in a active storage.

 Olly Headey [00:59:27]:
And, you know, with my tight fisted ways, I did you know, that that's quite a lot of traffic in my app just on one page. It's a lot of requests, you know, that I'm having to serve. They're like, I'm not these these images should really be on a CDN. Why are they even you know, the request should go directly to the CDN. I don't want these requests hitting my app. And that, you know, so that's where that was where I started thinking, well, how do I solve this? How hard can it be? And, well, it's not that hard, but it's it's quite convoluted. Like, so, you know, but there were 2 there were kind of there were sort of 2 related problems, but slightly tangential. One one being rails assets, you know, the CSS and the JavaScript and whatnot.

 Olly Headey [01:00:11]:
The other being the active storage, images and and solving those, getting those onto CDM, 2 different problems that did the the assets approach. Well, and I was using CloudFront because I was on AWS and all the images are on in an s 3 bucket. So I thought, well, CloudFront is the obvious thing here. That that that must be pretty straightforward. But, and I presume it's similar for other CDNs. I was just using CloudFront and has these free credits anyway. So, you know, it might as well. And configuring that and and this wasn't really documented in in the rails guides, particularly kind of, but not really.

 Olly Headey [01:00:53]:
And so getting the assets on there was one challenge, which involves kind of trying to understand exactly, you know, how to configure CloudFront and the bucket and cores and this kind of stuff. And then the other was how to do the act active storage assets particularly as well. And this is in a different use case, but similar in in with action texts. Some somewhere just active storage, you know, has one attached. So just a file attached to to a multiple files attached to a model. The other being in action text, you know, images that are inside an action text block to to so indirectly active storage, on my model. And trying to solve that was kind of an interesting one as well because you have to set up, particular routing, direct routes to do this and involved environment variables and different you know, and understanding how to actually configure this, cloud from CDN as well, which I have to say is is still part mystery. Like, I I I figured out how to make it work, but why specifically certain things I had to do when recommended configurations didn't actually work, is still a mystery.

 Olly Headey [01:02:13]:
And and I I I wasn't that interested enough to actually go and understand ex exactly why. But I did document it in this article. Like, here's what I did partly for my own benefit because, like, if I have to do this again, I'm literally never gonna be able to understand what to do because it, you know, it took me a a while to figure it out because not that information not that much information was was out there. Bits and pieces on the rails forums and various blogs. But so I thought I'd try and encapsulate it. And it just seemed to have worked because I have had a few people get in touch saying thank you thank you for writing that because I, you know, I I was banging my head against a bit more trying to figure out how to make it work. So, another thing I suppose that maybe that Rails could make a little bit easier although it is quite complicated, isn't it? All of this direct uploads, if you look at the code in Rails for how how that works, it's it's quite it's quite hardcore in my opinion. So that's that's the sort of top that's that's where it came from and and how I approached.

Valentino Stoll [01:03:16]:
It it's kinda funny because we we talk about, you know, your PDF's example as being, like, a great use case for Rails. I feel like files in general. Like, if you wanna just, like, get a file upload working, like, Rails is great

Ayush Nwatiya [01:03:29]:
Yeah.

Valentino Stoll [01:03:29]:
Before that. But, like, if you wanna cache it the right way, it's it's very complicated. But I feel like that's also true of anything. Right? Like, getting CloudFront hooked up to any app in any language is a complex process.

 Olly Headey [01:03:43]:
Like,

Valentino Stoll [01:03:44]:
and then how do you, like, you know what what is, like, a a famous saying, cache invalidation is, like, one of the hardest, you know, naming and cache invalidation? So, I mean Yeah. Absolutely. Can is there even a way to simplify this? Like

 Olly Headey [01:04:00]:
I mean, what what what the correct thing I should've done would would because it was AWS was to kind of write that as code. You know? Like, here's a Terraform script that will set up your you know? Right. It I didn't do that. It probably slightly beyond me or or or beyond my patience. I should probably say, I I have this patience problem where I'm just impatient. So the correct thing would be to study the Terraform and beautifully present this, you know, this is what I bought. I'm like, I haven't got time for this. I'm the the the the crazy thing is I of course, I have time.

 Olly Headey [01:04:34]:
I just choose not to. But, yeah, I I think it kept that could that could help because then you're expressing in code exactly what you're doing on this on on the cloud front and and on the s three bucket, in in the case, of active storage. But on the rails side, I mean, there's not that much to do. I mean, you know, once you've certainly with well, with with the assets, there's virtually nothing to do. You just have to set the asset host. It all the configuration is in in AWS where whereas with the active storage, you have to create this direct route. And then with that, action text, you have to then go and find the blob partial, you know, and go and change the route in the blob partial and things like that. But, once you've done that, it it it's kind of straightforward.

 Olly Headey [01:05:23]:
But it's, yeah, fiddly. But I think the the it's mainly fiddly because of the AWS. And if you if you could automate all that stuff yourself. But I suppose a good test would be to try it on another CDN, which I've not done. You know, would it work on DigitalOcean or or some of the, you know, people have the other image CDF image specific CDNs that may especially on the on the larger side of if if your app is, you know, big commercial app, you might not use CloudFront at all. You might go for one of these proper image CDNs. How I have no idea whether that would be easier or or more difficult, but presumably, from a Rails point of view, kinda the same. You just have to get this route point to the right thing.

 Olly Headey [01:06:06]:
So it's, you know, it it's it's more of an s s 3 platform problem, I would I would say, than than Rails.

Charles Max Wood [01:06:13]:
Yeah. It's interesting too because you mentioned, kind of the uploads and active storage. But one other thing that I thought about is just, my pre compiled assets, putting those on a CDN, for for a lot of the same reasons you mentioned. Right? You know, it's like, oh, you've gotta pull up, you know, maybe a couple of JavaScript files or my CSS or a bunch of images that, you know, they're not active storage managed. They're just

Valentino Stoll [01:06:41]:
Yeah.

Charles Max Wood [01:06:42]:
Right.

 Olly Headey [01:06:43]:
But, yeah, that the the the article does that that one is pretty straightforward, to do that. You you just have to once you set up your cloud front instance and set the kind of core stuff, then then you just set the asset host in in your rails app, and it, like, just works. Is that is that like, it it it just it literally just works. And, you know, that none of those requests are now hitting your app every time, you know, you you deploy, the cache gets updated. So, yeah, it it's it's great. Well, to my knowledge that, like, that that's a big improvement. Hasn't had any issues that I'm that I'm aware of. You know? I mean, CloudFront's pretty straightforward at some level.

 Olly Headey [01:07:35]:
Works really well. Obviously, you have to be what you do have to be an aid AWS for that, but it I guess it helps if you're all in in there. Right. It'd be interesting to know, though, you know, if you're I don't know. Depends what I think is. This is another thing, isn't it? Like, where where do people deploy their rails at? What's the go to thing? Because, again, nothing's perfect, but Kamal looks great to me. But then it's like, hang on. I've I've got a database.

 Olly Headey [01:08:02]:
What what do I do? You know? It's like, oh, well, you you know, do I have to pay Crunch data now? And, well, if I do that, then what if my, you know, my app is on Hetzner? But, well, do I now have to build my do I run that in a Docker container? Do I and that isn't that for me, that isn't covered whereas, actually, that's the that's the most important thing. I don't really care about my web servers. It's my database that I care about. And, you know, Heroku was good, but then they're kind of they're really tight fisted with their resources, which I I don't like, but, you know so I don't know. That's another whole conversation, I guess, in the front maybe for another time, but, the the definitive kind of I I think command is going I really like it. It's going in the right direction, but it doesn't quite get me what I want. Whereas, like, DigitalOcean, is it the app one, the Docker based one that they have? Mhmm. It is really good idea, but in practice, hasn't, in my opinion, hasn't been it's not great.

 Olly Headey [01:08:59]:
It's slow. But conceptually, it's great because you can get managed databases there. I can just kind of deploy my Bing via Docker. So that that that seems great. But, yeah, again, there's quite fragmented where do you host. People have different opinions on that. Personally, I've just I've just been using, like, AWS because I had loads of credits, and Hatchbox because it's just literally I don't even think about it. I just click a button, and it works, which I think is great.

 Olly Headey [01:09:25]:
And it supports Chris Oliver's brilliant, Hatchbox, so happy to hand him him money. You know? So that kind of interesting, but, Kamal, if Hatchbox had Docker, then it would that's it. It's kind of like it's almost game over at that point, I think. But

Charles Max Wood [01:09:43]:
Yep.

Ayush Nwatiya [01:09:45]:
I'm a big fan of, render.com. So quite they're a bit expensive, but, in terms of, like, ease of deployment, I just, I find it to be Heroku, but for 2024.

 Olly Headey [01:09:58]:
Right. Yeah. Seems to be pretty popular. Mhmm. But, yeah, I I I was just driven by because, you know, if you get if you go to AWS and you kinda go, hey. Here's my start up. I mean, you you can get you get, like, 2 years of all these credits. Great.

 Olly Headey [01:10:14]:
I mean, it's a it's a complete bait and switch thing from them, but actually pretty good. So you can kinda you know?

Ayush Nwatiya [01:10:20]:
I think

 Olly Headey [01:10:20]:
I got, like, $1,000. Kinda goes a long way. You know? It's great. Mhmm. But, yeah, ultimately, would I do that? Or maybe not maybe render. Yeah. Looks pretty cool.

Charles Max Wood [01:10:33]:
Cool. Well, let's let's go ahead and switch gears and do PIX, and then we'll wrap up. Ayush, do you wanna start us off with picks?

Ayush Nwatiya [01:10:42]:
Yeah. Easy one this this week. Haggis Ruby, new conference in Edinburgh in 24th October. Both Ali and I are speaking. So come for his talk, stay for mine. What else? Is there anything else? I'm about to rewatch the big short with my friend this evening. So a non tech big big short, if you haven't seen it, go watch it. Yeah.

Ayush Nwatiya [01:11:12]:
I've been coming up about anything else today.

Charles Max Wood [01:11:15]:
Awesome. Valentino, what are your picks?

Valentino Stoll [01:11:20]:
I've been working on this fun project called Podcast Buddy. He's actually listening right now. It's the AI companion that just lives in the terminal. And I can ask him questions right now, but I don't know what he'll respond with. So I'm gonna it's it's not polished, but he'd, you know, it just at the end of the episode here, he'll create some show notes for us on what everybody's been talking about in a nice organized format with links. So, it's it's really fun. I use it for meetings too, another version of it. I have a meeting buddy, and it's just so much fun playing with Whisper and, doing things locally, with all these LLMs and audio.

Valentino Stoll [01:11:57]:
It's a lot of fun. So check that out, podcast buddy. And then, I've been I found this, somebody has this project called the robot, where they're building a robot arm that has, like, a trainable robot arm that comes with that you could build with it to train it to do different things. And so somebody created a tutorial on how to do it all. And so I printed downloaded all the files and printed out all the parts. And I'll be building that just for kind of for fun to train a robot arm to do different things, in my office. So we'll see how it goes.

Charles Max Wood [01:12:35]:
Very cool. I'm gonna jump in with some picks. I always do a board game pick first. I I would sometimes get long winded, so I'm gonna try and make this brief. I'm gonna pick challengers. And I think I've picked this before, but challengers is effectively like war and capture the flag. So you flip cards over out of your hand until you've played more points than the top card of the other player, and then you get the flag, and then they do the same thing. When you lose the flag, then your cards go on to your bench.

Charles Max Wood [01:13:10]:
Once your bench is full and you can't place another card on it, your opponent wins. Or if you run out of cards in your hand, your opponent wins. And then you play 7 rounds. You rotate between the other players. It'll play up to 8 people. Right? So you have, 4 simultaneous matches going on at the same time, or 3 or 2 or whatever. If you have an odd number of people, there's a robot deck that kind of gets harder to beat as as the rounds go on. But, theoretically, you're drafting cards and building your hand or your deck up, so your deck should be stronger, and so you should be able to hold out with the with the robot.

Charles Max Wood [01:13:56]:
Board game geek rates it at or weights it at 1.78, which means it's pretty easy for casual gamers, and it's 8 8 and older can play it. So, anyway, that's my board game pick. I just finished a book. It's the book on mental toughness by Andy Frisella. You have to actually go to his website to get it. Walks through the 75 hard program, which I'm in the middle of right now. I'm on day 17, of of 75 days. And, it walks through the whole program.

Charles Max Wood [01:14:29]:
It's it anyway, I it's awesome. So, you know, it's it's part, physical health, part mental toughness, part other stuff. So, go check that out for sure. He also has a podcast, Real AF, which is, worth checking out. And then, I part of the program too is you have to read 10 pages out of a book every day. And so the book I'm reading now that I finished that is Awaken the Giant Within by Tony Robbins, and I am really liking this book. So I'm gonna pick that too. Ollie, do you have some picks for us?

 Olly Headey [01:15:07]:
Sure. Well, I'm gonna pick up Friendly RB, which takes place in September 18, 19th, I think, in Bucharest, Romania. And the whole I'm speaking there, but there's a whole bunch of much better speakers than me, which you should go and check out. I believe I saw some tickets left. I I have a discount, but you have to I can't I don't think I can announce it. You can find me. And if you want a discount, I can give you a discount for that. So I picked up that.

 Olly Headey [01:15:40]:
What else? I I had this kind I I've been on Twitter for, like, well, since back in the day. But, yeah, I kind of I've been checking out Blue Sky lately, which had passed me by a bit, but I kinda really like it. So I should probably be unmastered on tonight. I don't think that that kind of passed me by, but big up blue sky. Go and check that out. I think I think it's quite interesting what what they're doing. But I was gonna say, I don't know if this is gonna go out after the after the weekend probably. So, it might be too late for people at the Edinburgh Festival, but I I saw this show the other day with called sawdust symphony, which was one of the most incredible things I I've seen some crazy stuff at Edinburgh Fringe, but this was on another level.

 Olly Headey [01:16:24]:
It was the way they pitch it is carpentry meets circus. And it's like 3 3 German guys for an hour on the stage doing things with wood and the whole stage of it, including lathes and glue. It was honestly, it sounds ridiculous, but it's absolutely incredible. So you can probably see some videos of it online. Sawdust Symphony. I honestly, I've I've never seen anything like it in all my years, and now I I have a lot of years under my belt, these days, so that would be mine.

Valentino Stoll [01:16:57]:
This looks incredible. Thank you.

Charles Max Wood [01:17:06]:
If if people wanna connect with you, how do they find you on the Internet?

 Olly Headey [01:17:11]:
Yeah. I I would say on Twitter, but not anymore. I got the website, hedi.net, and that has my links. I'm on Blue Sky and threads, kind of, trying to say hello, Instagram,

Ayush Nwatiya [01:17:27]:
or

 Olly Headey [01:17:27]:
just email me. I'm just ollie@hey.com. So, yeah, that's how to find me, but hedi.net is my kind of home, I suppose, on on the Internet with my blog and stuff like that.

Charles Max Wood [01:17:40]:
Awesome. Well, thanks for coming. This has been

 Olly Headey [01:17:43]:
Great. A lot of fun. Thanks for having me.

Charles Max Wood [01:17:46]:
Yeah. Yeah. We'll wrap it here till next time. Max out.