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!SocialsLinkedIn: Olly HeadeyPicksCharles - Challengers! | Board GameCharles - The Book on Mental ToughnessOlly - Friendly.rb - Your friendy European Ruby conferenceValentino - PodcastBuddy Become a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.
Hey folks, welcome back to another episode of the Ruby Rogues podcast. This week on our panel we have Ayush Nwatia.
Hello, hello.
We also have Valentino Stoll. Hey now. Charles Maxwood from Top End Devs and we have a special guest this week and that is Oli Heddy.
Or heedy, actually. Heedy.
No, 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 want to 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. Yeah. What else is there to know? What else are you famous for?
I think you've done it really well. For a start, am I famous? I don't think so. But they're the two main things, really. I mean, free agent. you know, consumed 15 years of my life. So, you know, that's pretty much most things. Before that, I was a software developer, you know, nothing out of the ordinary. You know, it started in the 90s.
I used to do computer games originally when they came on CDs and had sprites, that kind of game. You built them? Yeah, that was my first job. I was just a programmer writing C, C++, and making characters move on the screen. So that was kind of interesting, although quite hard work, I have to say. If you just want a 9 to 5, I wouldn't recommend video games.
My son wants to be a video game developer, so...
yeah i mean great fun i mean to be honest probably quite different in the 90s i have no idea what it's like today i'm not really yeah in there um but but yeah and then you know doing a variety of different jobs uh and ended up being a being a kind of consultant you know going into banks kind of soul destroying that kind of thing and then yeah and then
we had it's funny because we had i had this accountant um to do my you know to do my books had a limited company um and he used to send a spreadsheet every month and say fill this in you know so 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, what you owe this much tax, pay it here. So I had no idea about how finance about the finances, how it all worked or anything. And it just felt like a bit of a waste of time. And, you know, so as it turned out, Ed, who is another co-founder of the agent he had,
He had the same accountant and he'd been, you know, he'd started work on this prototype of free agent using Ruby because that was super cool, right? In 2006, that was the real hot tech. And I met Ed and, you know, we kind of got talking, found this connection with our accountant and he was a bit like, well, do you want to kind of help me build it? And I thought, okay. And then quit my job.
And that was that. So that's kind of how it came about. And yeah, 15 years later, kind of. I left because we did an IPO in 2016 on the London Stock Exchange and then and then we actually got acquired by a bank.
um in 2018 and so i kind of stayed there for a little while after that but then yeah left in 2022 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 app pretty much not quite but pretty much was it hard to let it go Let it go. Well, I mean, yeah, yes and no. I think yes and no.
It gives you that sense of identity, you know, and so you sort of lose this whole thing. It's like, yeah, I'm the co-founder. Well, you can always say co-founder, can't you? But, you know, you can't really you detach from it then.
but then but then not really because you know i think it for me i felt like we'd almost built everything in it like every feature was kind of done in my mind like um it did everything from like time tracking all the way through to kind of filing your tax returns uh automatically but at that point it's like we kind of you know felt like it was kind of done that's what we set out to do back in the day and you know i thought we'd never get there but we did um
The last thing we did was this massive migration of the infrastructure to the cloud. None of this cool move out of the cloud. We'd run the whole thing on servers, our own servers, for years. Then in 2020, we moved to the cloud, AWS. That was a big thing. For us, it was a good thing. Once that was done, I was like, yeah, I think I'm I think I'm kind of done here. But I do miss it.
I still use it as well because I do my own kind of consulting thing now and again and I'm still used to it. I'm in there quite often. It's good.
Yeah, I'm 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 free agents. So it's been a boon for me as a freelancer to have that. So what was the motivation behind going to the cloud? Because obviously with 37signals, all the rage is going the other way.
Yeah, absolutely. DHH made Kamal so that he could get off the cloud.
Yeah. It is a good question. I mean, I guess for a start, I am a big fan of running your 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 you know and we did use there was all these cloud 82 sort of existed but um
early days, you know, it wasn't much tooling around that. And there were things like flight hosts and these other cloud bright box, a few of these things that we did play around with just for staging servers playing around, but the actual app ran on it, run its own hardware. And we did at one point Rackspace had a cloud and because we were Rackspace, we were like, let's use that.
This would be great. And 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 just great at building servers and stuff, networking and whatnot. So we just decided, well, let's just do it. And we just bought some hardware and racked it up and did all that. And that's how it ran for...
well what would that be about nine years um but i suppose one of the big drivers was the tech we were using um was kind of niche we were using towards the end uh smart os which you may or may not have heard of i i don't know not many people have heard of it so which is basically like uh ultimately it's solaris but it's uh
an alumos um and we were using triton to do um containerization and all of this but it wasn't docker it wasn't linux it was it was kind of niche worked really well but actually The ops team, we struggled to hire people to do it for that reason, and also didn't necessarily want to do it as well, most people. So it was a little bit troublesome.
And obviously the cloud had come a long way, which we were already using. We already were using S3, like all the receipts, everything that you can upload to free agents, all in S3. And that was always the case, because you don't want to 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 kind of made sense to us. Well, let's just think about moving the app over how, you know,
how hard can that be and there's lots of advantages and because we've been bought by a bank they they were um 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 so we could kind of piggyback on some of that so all of that coming together uh really helped um and yeah it was It was a good move for us, I think.
I mean, cost-wise, very hard to compare. I mean, maybe it's more expensive. I mean, 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 as code, which we already did, but we were using Popit and other technologies that, you know, kind of moved over to Terraform and 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.
And so, yeah, it was actually a pretty good move, I think. But I do kind of miss the power that you get from your own hardware. It's got to be said. Some of 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 squeeze you know squeeze the margins improve things then sure but we were optimizing really for a big engineering team we had 100 plus people
not a very big ops team, and we only had about five people doing all of that, which was about half the size of 37signals. So yeah, I think that answers your question. Bit of a ramble.
Now that's very, very thorough. And so yeah, you left in 2022, and then did you go immediately to 37signals after that?
um yeah i mean i hadn't i didn't intend to do that because i knew i was leaving free agent um and at the time there were a couple of guys that had worked at free agent um that had gone there they'd gone they joined in like the summer of that year 21. um and you know absolutely in touch with these guys really great great programmers um you know fantastic people um
And at the time, they were looking for a director of engineering. And I think one of these guys said, we should talk to Ollie. He's leaving Frasier. Maybe he'd be interested. And so it was kind of like a recommendation that happened.
you know i got the i got a call from david and said do you want to chat about this and you know one one thing led to another and i was like this sounds pretty cool and and um because quite a few people from free agent when i when i then joined i joined in march 22 um by that point they'd hired about i think there was five people that were programmers and free agents.
It felt a bit like getting the gang back together again. I thought this would be quite cool. I can go and work with these guys who are amazing and get to work with 37 Singles. That sounds brilliant.
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?
I suppose it does look like that, doesn't it? But yeah, I think, well, my involvement in the cloud exit at 37signals was pretty minimal. I mean, to be honest, I wasn't involved technically really in many things there. It was very much more of a management leadership role. So... Unfortunately, I didn't get stuck in.
Fair enough. So I'm not saying this just to blow smoke up your ass, but FreeAgent has one of the best web UIs of modern software as a service app that I've used. And I was chatting with some of the FreeAgent guys 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 2010s.
How did you avoid this whole hype cycle of React and stuff? Because the way I see it, most web UIs are shit because people use React and shoved it where it has no business being. It's a great tool for the right job. But obviously, I'll avoid the rant right now. But how did you avoid the hype cycle? Just keep things simple. And as such, it's got a very snappy UI.
Yeah, Ollie, how are you such a genius? Such a forward-thinking genius.
Well, I'd love to claim that, but let's dive into what the reality under the hood is, shall we? So, I mean, front end, right? Like, back in 2007, the noughts, it was all, you know... prototype JS, that kind of thing, right?
Oh, you're going way back.
That's how it was. That's when I got started, was prototype.
And then jQuery was like the dream.
Yeah, we didn't have jQuery, but until we... I suppose, fortunately, in some way, we just didn't really do that much JavaScript. I think the only places we really had it were populating combo boxes, that kind of thing. When you change one, the next one populates. A few things like that. So we kind of avoided it just because, well, I wasn't really very good at JavaScript.
I don't think I am very good at JavaScript even now, to be honest, because I just try to avoid it as much as I can. And then jQuery, I guess, came along and we used some of that for a while. And I think part of the thing was that free agent's scope was really broad. So when it came to dev, 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 had to do back in the day. There was this huge scope of stuff. So like faffing around and rewriting UIs. was not really a useful business thing to do. So we just kind of didn't do it. We just left it.
Now, except that one of the most kind of interactive parts of the app is the banking area where you have all your bank transactions and you kind of click and you can explain them and categorize them. Now that probably 20, trying to think 13 or something like that. I think someone had started playing around with, with a JavaScript framework.
I can't remember off the top of my head, actually, what that was called. 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 kind of works. And they got it working quite quickly in a few days, prototyping this thing. And it was better.
It worked better from a UI point of view. But then it kind of 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 much more complicated. It was quite buggy because like all the validation was on the server side.
So all the front end validation 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. So it's all a bit of a mess, to be honest. And as far as I know, that is still there. That whole banking area in FreeAgent is React app.
Well, inside the kind of mainframe. There's not so much single page. But then, honestly, I... Now, I could be slightly wrong here because it's going back a few years, but then... So everything else kind of 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 kind of made the call like nothing else in react forget about it we're just going to leave it as it is and gradually improve things by which point turbo and stimulus was coming along um and by the time i left then it was like right the future should be in so we'll just stick with the rails convention and we'll do stuff that way um 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 um technologies so it's you know we we did through general ignorance we we didn't you know rebuild the entire ui in react 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 um using kind of
I don't think we used React Native, but I think we talked about doing that, but we ultimately just went with Native. But yeah, so it's because of the size of FreeAgent, there's a lot of different tech going on. 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.
Because these things are quite hard to extract. It's a lot of effort and for pretty much zero user benefit, pretty much. And they kind of work, right? So it's tricky managing things on that scale, I think.
Yeah, 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's just wasted effort. So yeah, if it works, just leave it, let it work.
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 going to spend six months rewriting this piece, right? So you have to weigh all these things, but 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 allowed us to deliver better and faster in the future.
I feel like, you know, like 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.
Yeah, but I mean, I guess what's tricky as well is when you have a lot of engineers, you know, dozens and dozens of engineers...
get a lot a lot of opinions as to what is the right thing thing to do um and even when you know you're talking about well let's do we'll do stimulus that's how we're going to do these things you know then you're going to people are going to say well great can we use stimulus reflex can we do that because here's a good reason 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 all know what you're working on but in reality it's like if someone thinks they can do that there's a benefit to doing that is is it bad is that dangerous are you going to end up in that situation where you're just using an obsolete technology that you have to then replace or actually is it fine it's you're kind of making bets regardless of what you do um
And sometimes the stimulus is good, isn't it? But in my experience, which isn't huge, to be fair, I think it's quite opaque in terms of exactly what is the best practice like for an infinite scroll? I don't know. If you Google it, there's loads of ways of doing it. Which way should I do it? And not a contrived example, maybe.
That kind of thing where it's kind of, in my opinion, quite vague documentation about how to do stuff. You are kind of left to Googling or ChatGPT and hoping it comes back with stuff. And it's the same in the business. It's like, well, I want to use Stimulus Reflex. Is that bad? I'm just going to include this particular JavaScript stuff and it's going to fit our needs here. Is that bad?
Or is that good? I kind of think it's okay, but I'll kind of keep an eye on it Whereas with React, that's very much different paradigms. That's much more complicated, I think. Whereas just JavaScript libraries, yeah.
So how do you assess switching to new technologies or adopting new things? What is your thought process on doing that?
I think my default is always, well, why do we need to change anything? Can we just not? Because changing stuff is just like work and it's going to take longer than anyone says it will. And so can we just not? And there are people out there that still build stuff with jQuery and stuff because it just works. Is that bad? Who's that guy on X who's like,
the millionaire hacker guy, the nomad list guy, Levels, Peter Levels. And I think he builds all of his stuff in PHP and jQuery, doesn't he? He can build anything with this stuff. I think if you can resist, but then when you say you're resisting change, then you're kind of like an old dinosaur, aren't you? You don't want to change.
But the reality is when you're running a business, you just you do have to kind of focus mainly on customer value. And if it's not going to bring that value or maybe like increase. dead velocity by an order of magnitude or something, then do you really need to? Or is there, if you are going to do it, then how can you do it incrementally? You know, how are you going to do that?
And it's like, if you want to go back to know turn everything into stimulus that's great don't do the big stimulus project that's just going to take 18 months um to do it bit by bit you know like we're going to work on this banking area let's just tackle that one while we're while we're in there that that's more of the approach i i would really take i think um
resist as long as possible until it became glaringly obvious that either everyone's going to walk out uh which is you know not with our cloud stuff you know i don't think people are going to work walk out but i think if we really tried to keep forcing kind of smart os triton down everyone's throat i don't think it would really ended well we're gonna we have to do something there um but from a programming point of view
I'm not sure how common that problem is, really. But you do tackle hard ones, like a Ruby upgrade. What's good about things like that is that you know, you get the obsolescence. So you know that if you don't fix stuff by this date, then you're unsupported and you're in dangerous territory at that point.
So that's quite nice when you have these actual... So if someone said, right, jQuery is getting turned off, you can't really do that, can you? But if they did, then maybe that would be a good thing to do. But yeah, but to try and simplify it as well, though, because... That's always a challenge to try and keep the stack and everything as simple as you can, which is hard.
And it's something that 37signals obviously do really well. But then they have fewer moving parts, I think. And they invent all that stuff anyway, so it's kind of different.
Yeah, the simplicity side of things is huge for me. And I also have an allergy for dependencies. I hate pulling dependencies. I will need to have a really, really good reason before I add something to my gem file. it would be like, literally, I do not want to solve this problem by myself. And that's when I'll pull in a gym.
Because I think most of the time, you could just spend two or three 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.
Honestly, that's such good advice. I think, yeah, I We maybe didn't heed that. There's always this tension, isn't there? It's a bit like a build versus buy, although it's open source. You're not really buying. You're just kind of borrowing.
But yeah, when you come to do a Rails upgrade and that one gem that you use for tagging or whatever it is, there's some gem and it's just like, oh shit, it's unsupported for Rails 6. You think, well... But if you wrote your own, it's probably like a couple of classes and it's not very complicated. You could do that yourself. And that's something, you know, 37signals do so well.
Their gem files are pretty small, really, whereas Pretty Short Pre-Edge is pretty large. And it's definitely something I've taken on board a lot. I think that it is good practice to try and minimize as much as possible. I do remember at 37singles when they were starting on, I guess it was the calendar app. And I think David's looking at these genpads and basically, why have we got Redis?
Why is Redis in there? And it ultimately led to kind of the solid cache and solid queue stuff, which is just like, hang on, database is really fast. What are we doing? We 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 these gems being built. Like, I'm sure they're fast enough.
You know, databases are fast enough now on these new drives we've just bought. We don't need race. And it's almost like I don't know. This is what was in David. It was like that. 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, first grade, right?
Because 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.
I'm curious on your thoughts about this idea, because I have a total agreement, fewer dependencies the better, but at the same time, 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 gem is like worth it uh over building it yourself yeah i mean for a start i suppose you have to have to look at the activity on it don't you if it's an active gem then
and pretty entrenched in the community, then that's always a good sign. I don't think I would hesitate really to use the gem in that case. Unless, as I say, it was so simple that you just think, well, do I really need to do that? Because sometimes they can complicate things and sometimes not.
the hard I suppose the harder the problem that you're trying to solve by using that gem then the more likely I would say it's probably better to use a gem at least in the first instance right and and if 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 your goal is to move fast and just get stuff done then you know bring in devise right like most people do that I don't know whereas you know
I built a couple of little apps recently and I thought I'm not going to 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 but then I've had the same problem with apps where I've used device
And then I've wanted to kind of rip it out because it was too painful to go and adjust that template of some password. I can't even remember the examples, but you know, some sort of, it shouldn't be that hard. And I felt 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 time you have available, what your kind of skill level is at some level, I suppose. If you really don't want to get into that, then why bother?
But if you're building a product, you know, like Reagent or something that's at 37 Signals, maybe you just kind of, you do want to own that yourself just in case device stops or if it deviates from what you need or if you want to customize it, then maybe it's just a bit too hard That kind of thing.
But again, another app I built had Google Auth, which I thought was going to be straightforward, but that's my own naivety showing there. But then I tried OmniAuth, and there were certain things, it was slightly out of date. It was a little bit fiddly. So I think if you're a business and you're well-funded or making money...
yeah i don't know but if you're a business you're making you're making money or you're well funded then you know maybe you should build your own if it's not going to be too onerous to do that because then you own that tech and you can support it without question but If you're in the early days or if you don't have that capacity, just use the gem and hope for the best. But these things change.
It's like active storage. We used, well, originally at FreeAgent, I think it was Paperclip or something, pretty good. And I think it's, I can't remember, I think, didn't it get, it got support stopped. So then we moved to Shrine.
And then I think active storage appeared, but then I think we left it on trying, but then that now it's like, Ooh, 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. Well, I'm glad we didn't build our own. One of those, to be honest, I think managing storage upload would probably have not been a great idea.
I'd rather migrate from one to the other at that point.
At least you're not someone like ThoughtBot that has like all of their clients using their thing and that they now have abandoned and upgrade everybody and worry about that. But I'm curious, like, so let's 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... As a web framework, what do you mean they're using...
Yeah, for like, you know, just Sinatra 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 new 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?
I mean, it's a good question, but I suppose, yeah, it depends what the problem is. I mean, for a web app, I would just use Rails. I mean, you could say, well, there's quite a lot of baggage, isn't there? Is there? Yeah, sure, you can write a Sinatra app and a few files. But then a Rails app... you're only really populating a few files.
You go to like your roots, maybe you've got a controller, 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 don't know why I would bother doing that. I mean, maybe there's like an overhead and like memory or something. I don't really know.
Maybe there's a thing there who knows, but yeah, Personally, I would just use Rails. But yeah, command line apps, we would not use Rails for that. I mean, it depends. At Frasian, one of the... One of the main things it does is PDFs of invoices. You can download a PDF, attach it to an email, all of that.
So that's the kind of thing that we wouldn't do in Rails because, well, I think it's not straightforward. So we had a Java thing that generated that. But Rails would call it. So it was the Rails app that was kind of talking just to an API to generate this PDF. So that kind of thing. We wouldn't be fundamentalist and go, it has to be in Ruby, it has to be in Rails.
But just when there's a best thing for the job, you would use that if it's not too objectionable. But honestly, Rails, I don't know why they're not talking at conferences that much about it. I mean... I suppose what is there, well, you have Rails World now, right? So that's going to be all about Rails. So maybe the other conferences want 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, people are doing like data stuff with Ruby, aren't they, these days? I mean, I know Python's like the go-to kind of language for that kind of stuff, but there aren't.
people trying to do stuff in Ruby, which I think is pretty cool, but I'm not, yeah, I wouldn't be fundamentalist about it, but if I was building a web app, I would just use Rails because it just works, right? It's great.
Yeah, just pulling on this dependency thread a little bit more, like going back to your authentication example, I do my own auth. I don't like devices. I don't like pulling in anything for 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 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 kind of think about a lot is that trying to maximize the reusability of code. That's not necessarily... in a way that it can be extracted to a library because it's different when you've got code living in your app and when you're kind of extracting something because when you put it in the gem, it's more of a black box. But yeah, copy paste code.
Once you've solved 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 don't know what you think about that kind of approach.
Yeah. I mean, that's, that's kind of, kind of happened. I suppose of the apps that I built, one used Google auth, so that was slightly different. And then, but the, but the, One used email authentication and one would use a password. So they're all different for whatever reason, for because reasons. But no, I would probably do the same. I think, I mean, Rails has baked into it, doesn't it?
It has secure password stuff. It's kind of baked into it now, which is great. So it's pretty easy to do that. I suppose things like the forgot password is that boilerplate of stuff. But it's quite small what you really need to do. Kind of validate the email address and forget a password. 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. 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. But yeah, I suppose that's how I do it.
But then, but also what about when, you know, because usernames and passwords are unpopular perhaps these days. I mean, what I see using various apps around the internet, you know, is, well, 2FA, right? Like, how are you going to do that? And also, are you going to do it with SMS, email, or send, you know, one-time passcodes? And there doesn't always, are you going to go with pass keys?
Cause that isn't a new thing now. And it's, I'm not sure I would do that myself. Uh, even 2FA, you know, I don't know if you've done that yourself or not, or maybe, I mean, that's maybe something that rails can, um, We'll get baked into it at some point. Maybe that's the trajectory it's going or pass keys. Maybe that'll come. That might be a good thing.
Kind of surprised it hasn't got, Rails doesn't have a device built in, to be honest.
Feels like it maybe should. There's going to be something in Rails 8, some kind of generator, I think, that gives you a skeleton of authentication. And I think I remember seeing a tweet from DHH a couple of years ago that they might do something similar to has secure password, but for one-time pass keys. There's an authenticator app. What's it called? TOTP, I think, the time-based ones. Yeah.
I think there's some, I saw some chatter about like a has secure password flavor of that kind of thing. I don't think anything's actually gone in, but yeah, it'd be good to have for sure.
Yeah. Dave is action off too. That's pretty great.
Yeah. Action off is nice. The thing is, is that, you know, kind of what I used to talking about, Um, I've, I've wanted something more like zero authors where essentially it is the generator that just sticks the code in. Um, I mean, I've, I've looked at the code for action off.
It's, it's pretty easy to follow, but yeah, it's still, to me at least has that feeling of that black box where, um, you know, the zero 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 that's kind of the thing that I really like.
And so, um, I, I'd love to see a lot of these common problems. In fact, um, I negotiated with, uh, Daniel Kehoe. I don't know if you guys remember him. Um, but he, he had a series of rails apps that he had recorded videos of himself building way back in the day. And, uh, he had, uh, a project called rails composer. And essentially it asks you a bunch of questions and then populate your gem file.
Um, 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, 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,
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. And it's funny because initially I was going to do engines. And then I started reading Ayush's book. And it walks you through building the authentication. And I'm like, this is just so much cleaner now.
in so many ways and I can make this into whatever I want. Right. It gives me the freedom to just do what I need. And so, yeah, I can give you all the pieces. It'll have a nice interface. It'll all be tailwind or whatever. 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 it to trigger some jobs, well, it generated the code. It's in your code. You check it in so you can change it anyway.
Yeah.
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 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 could go look at it.
I'm sure it's relatively easy to follow along with. But yeah, then why do it the other way?
Ali, I'm curious, like, you have a lot of experience in, like, product development and, like, the business-focused aspect of, like, building things, right? So I'm curious, like, what your thoughts are on, like, you know, where... the technology is most helpful in the process, in the business side or developing the product?
And why are you still sticking with Rails at this point with all of the other stuff that's available? Is it familiarity? Or where do you see the technology really aligning with that aspect?
Yeah. I mean, that's a good question, right? Because, well, I'm not kind of setting up a big SaaS business right now. But if I was, would I use...
use rails i mean me personally if i was like a founder founder cto again i probably would mainly because that's like all i know and i'm kind of institutionalized 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 good choice because um 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
B2B SaaS space, of course, like that, which is, you know, but that said, you know, it depends what you're building. If you're, you know, if it's a consumer app, are you going to be able to do what you need to do on the front end with, you know, Rails stimulus? Is that, you know, good enough? Or do you actually need to lean on the community of more JavaScript stuff?
whether that's React or Vue or whatever else. I mean, you can still use Rails on the backend, but are you then moving into a different architecture driven because of your needs on the front end? I mean, maybe that would be a different consideration. I think at one level, I honestly don't think it really matters because technology is not usually...
The thing that kills businesses, it honestly doesn't usually matter. The main problems with businesses are product market fit. You've built something and no one wants it, or you've marketed it wrong, or you can't get the distribution. That's usually the problem, not tech. Businesses don't usually fail because someone picked Rails or someone picked TypeScript or whatever.
That doesn't seem to be the... a pattern. So I don't think it really matters. But what I do think is interesting, so I do kind of talk to a lot of startups, done some kind of like investing and stuff, but, you know, and generally in the startup community, I'm virtually non-use rails. In fact, maybe none that I've spoken to that is.
Whereas React on the front end and something on the back end that is typically Node-type script, maybe Python, is the prevalent tech of today, which I find quite fascinating. But these teams move fast. They get stuff done.
you know just like we do with rails so you know but it's arguably a bit more is it more complicated 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 um which you know there are legit use cases for doing that kind of stuff
But at some level, I don't think it really matters. I think Rails is still a brilliant choice. I would do that. But again, that's because I'm probably institutionalized. But I wouldn't go and learn new tech just so I could build unless it was for a specific advantage. If you were doing some kind of AI stuff and you must use Python, then sure, do that.
Is there an example in Rails where you found that feature being there just saved you a ton of effort if you had gone with something else in the moment?
It's a good question. I was doing some stuff earlier this year that did kind of touch on, 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 have JavaScript, I can't remember, JavaScript, Python, Java,
maybe C sharp, maybe, because it was Microsoft, I can't remember. But those are kind of the libraries and the SDKs that they offer. They don't offer Ruby, which is a shame, but there are gems that kind of wrap this stuff up. And so that was quite interesting. But then some of the functionality that, I mean, AI is 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 machine learning algorithms, which Ruby doesn't really quite have. I mean, there are people that are creating similar libraries out there for some of this stuff, but it always feels, I don't know, not quite there. From an AI point of view, depending if you're just calling APIs, of course, fine.
You can do that from anything, but if you're then trying to do some stuff yourself using the cut, then it doesn't quite feel like the right choice, but maybe that's changing. I it's only superficial knowledge that I really have of that. Um, but I can't think of 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. we're going to do it with prawn or something, whereas we were using Java libraries that actually did proper PDF rendering. But there were other ways we could have tackled that, but we chose the the different tech path, as opposed to finding a Ruby way to do that.
I'm sure there are lots of other examples, but I think where Rails does seem to shine is when it's much more of a, well, people call them crud apps, don't they? It's kind of a bit demeaning. It's like the 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 million 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. And what isn't? Notion's a crud app, isn't it? I don't know. So that's, who knows? So a crud app, I'm a bit like, hang on. That's everything at some level, isn't it?
Part of maybe chat GPT or something, but we're not building that.
Yeah, most apps are crud apps. I think it's just something people don't like saying. My client at the moment is actually is a startup and we're completely rails. So there is at least one startup. And I had briefly spoken to another startup a couple of months ago about working with them and they were going to be completely Rails as well.
The way I see it, if there's something that you can't really do in Ruby or in Rails, it's usually something with quite a small footprint and you can just extract that into its own service and build it using something else. Like the PDF thing you said, you can't do that in Ruby. Build that one tiny thing using something else and then just call it.
Yeah, and I think that's entirely the right approach. But yeah, good to hear there's, you know, more startups that I mean, a lot of people building like indie hacks, which is kind of like another kind of release derogatory terms, but actually kind of, that's where everything starts in a way. You know, using rails, it's just, you know, a lot that I've seen. So
you know hopefully we'll kind of see i think this is where like the rails foundation does come into play you know there's a lot of money there um and they're doing some cool stuff there's obviously the conferences um and the guides looking a lot better now but for me it's like the outreach and and how how can the rails foundation just um get people at an earlier stage and
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 JavaScript ecosystem, which feels, I don't know, I mean, to put yourself in the place of someone on a boot camp who doesn't know anything about programming and all of a sudden you're having to do React, it sounds...
overwhelming to me whereas at least with Ruby it's like kind of here's an ERB template and it's just basically HTML that feels a bit less but maybe when 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 going to be an important part of Rails future success is to get in the ground again and make people realise that how
great it is and i think you know that's part of the job of the rails foundation but
get everyone else shouting about it as well really um so hopefully i'm i'm hopeful that this is uh this is already happening and we'll get better as well as people because there was a talk wasn't there was it um irina from uh evil martians and she did a talk about uh startups on rails or something i didn't see the talk i think i've seen the slides and you know she talks about
some really interesting companies and companies that were built in other techs that are moving back to like a Rails. We were all microservices and now we're going to come back to a Rails monolith because frankly, it was just chaos. And now this is far simpler and we didn't really need all of that complexity and distribution.
We just needed an app with a big database and that goes a long way usually. So hopefully we'll start to see this change.
Yeah, I think boot camps have just kind of generally moved away from teaching web fundamentals. It'd be good just to have them go back to teaching literally the basics of web development, HTML, CSS, JavaScript, and obviously I'm biased, but Ruby and Rails. Because last year 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 helped out with the mentoring. And she was a boot camp graduate. She graduated from LeWagon quite recently. And they had a little bit of Rails and quite a lot of React in the curriculum, if I remember correctly. And I remember showing her what you could do with just a custom element in JavaScript. And it was like, whoa, this is so easy.
And it's like, yeah, I just wish boot camps would teach that kind of stuff a bit more. Yeah.
And like you say, you know, teaching JavaScript is super important. You have to kind of know JavaScript, but not necessarily at a hugely complex level. You know, like you say, little sprinkles of the JavaScript is often more than enough to accomplish what you need to do. And certainly at the boot camp level. But on the other hand, it's this chicken and egg problem.
They're trying to get people jobs. That's what they're there for. And if all the jobs are REACT, then it's their duty to then go and teach people what's going to get them most likely to get the job so they can have their placement stats nice and high. So it's a tricky one. You need the jobs.
otherwise the boot camps might say well this movie stuff is a bit weird isn't it 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 um yeah tricky
Yeah, 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 kind of fall back on and then learn something else. But that's a different discussion, I think.
Yeah, I think so. It's pretty entrenched, I would say now, I think, pretty much.
Yeah, that's true.
Here to stay.
Sadly.
Well, anything else that we want to dive into here?
We didn't touch on the old Rails assets, the original article that you got in touch about, I suppose.
Yeah, we should definitely do that here for a minute. I actually am kind of curious about it. So I have to admit, I haven't read the article yet. I didn't see that that was... I'm working on a better system for letting us know what we need to read in order to prepare. In the meantime, yeah, you know, I think...
Well, actually, why don't you just give us the 10,000-foot view on what the article is about, and then we can kind of attack it.
Yeah, of course. So it was one of those things where I was running an app, and I'm loathe to pay anything more than I need to, the absolute minimum amount for a server to run this thing on, right? And it's using active storage to store uploaded content, right?
But the particular app that I was building involved customers uploading photos in bulk, so dragging potentially hundreds, small hundreds of photographs into a drop zone thing.
and uploading them all and then viewing these things in the app so you can view you know three four hundred photos in a gallery um of course it's like infinite infinite scrolls on but this is quite a lot of requests on the app when your images you know are in active storage uh and you know with my tight-fisted ways i did you know 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 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 quite convoluted. Like, so, you know, But there were two related problems, which are slightly tangential.
One being Rails assets, you know, the CSS and the JavaScript and whatnot. The other being the active storage images and solving those, getting those onto CDM, two different problems that the assets approach. Well, and I was using CloudFront because I was on AWS and all the images are on in an S3 bucket. So I thought, well, CloudFront's the obvious thing here. That must be pretty straightforward.
And I presume it's similar for other CDNs. I was just using CloudFront and had these free credits anyway, so might as well. And configuring that, and this wasn't really documented in the Rails guides particularly, kind of, but not really. 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 cause and this kind of stuff. And then the other was how to do the active storage assets, particularly as well. And this is in a different use case, but similar with action text. Some were just active storage assets, you know, has one attached.
So just a file attached to a multiple files attached to a model. The other being an action text, you know, images that are inside an action text block. 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 understanding how to actually configure this CloudFront CDN as well, which I have to say is still part mystery. 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 and and i i wasn't that interested enough to actually go and understand 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 going to be able to understand what to do because it you know it took me 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. So I thought I'd try and encapsulate it. And it does seem to work because I have had a few people get in touch saying, thank you. Thank you for writing that because I was banging my head against a brick wall trying to figure out how to make it work.
So another thing, I suppose, that maybe that Rails could make a little bit easier. Oh, look, it is quite complicated, isn't it? All of this... Direct uploads, if you look at the code in Rails for how that works, it's quite hardcore in my opinion. That's where it came from and how I approach it.
It's funny because we talk about your PDFs example as being a great use case for Rails. I feel like files in general, if you want to just get a file upload working, Rails is great for that. But, like, if you want to cache it the right way, 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.
Yeah. And then how do you, like, you know, what is the famous saying? Cache and validation is, like, one of the hardest, you know, naming and cache and validation. Oh, yeah. Absolutely. Is there even a way to simplify this? Like...
I mean... The correct thing I should have done, because it was AWS, was to write that as code. Here's a Terraform script that will set up your... I didn't do that. It's probably slightly beyond me, or beyond my patience, I should probably say. I have this patience problem where I'm just impatient. The correct thing would be to study the Terraform and beautifully present this.
I haven't got time for this. The crazy thing is, of course I have time. I just choose not to. But yeah, I think that could help because then you're expressing in code exactly what you're doing on the cloud front and on the S3 bucket in the case of active storage. But on the Rails side, I mean, there's not that much to do. I mean... With the assets, there's virtually nothing to do.
You just have to set the asset host. All the configuration is in AWS. 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's kind of straightforward. But it's, yeah, fiddly.
But I think it's mainly fiddly because of the AWS. And if you could automate all that stuff yourself. But I suppose a good test would be to try it on another CDN, of which I've not done. You know, would it work on DigitalOcean or
or some other, you know, people have the other image CDNs, image-specific CDNs, and they, especially on the larger side of, if your app is, you know, a big commercial app, you might not use CloudFront at all. You might go for one of these proper image CDNs. I have no idea whether that would be easier or more difficult, but presumably from a Rails point of view, kind of the same.
You just have to get this route to point to the right thing. So it is...
you know it's it's more of an s3 classroom problem i would say than rails yeah um it's interesting too because you mentioned um kind of the uploads and active storage but one other thing that i thought about is just um my pre-compiled assets putting those on a cdn um For a lot of the same reasons you mentioned, right?
You know, it's like, oh, you've got to pull, 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... Yeah. Right.
But yeah, the article does... That one is pretty straightforward to do that. You just have to... Once you've set up your CloudFront... instance and set the kind of core stuff then you just set the asset host in your Rails app and it just works it literally just works and you know none of those requests are now hitting your app every time you know
you deploy the cache it gets updated so um yeah it's it it's great well to my knowledge that like that's a big improvement um hasn't had any issues that i'm that i'm aware of you know uh i mean cloudfront's pretty straightforward at some level. It works really well. Obviously, you don't have to be an AWS for that, but I guess it helps if you're all in there.
It'd be interesting to know, though, if you're... I don't know. The thing is, this is another thing, isn't it? Where do people deploy their Rails apps? 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 got a database... what do I do? You know, and it's like, you know, do I have to pay CrunchyData now?
And well, if I do that, then what if my, you know, my app is on the Hetzner and, But do I now have to build, do I run that in a Docker container? For me, that isn't covered, whereas actually that's the most important thing. I don't really care about my web servers. It's my database that I care about.
And Heroku was good, but then they're really tight-fisted with their resources, which I don't like. So I don't know. That's another whole conversation, I guess, maybe for another time.
uh the definitive kind of i think kamala's going i really like it it's going in the right direction but it doesn't quite get me what i want whereas like digital ocean uh is it the app one the docker-based one that they have is really good idea but in practice hasn't in my opinion hasn't been that it's not great a bit slow but conceptually it's great because you can get managed databases there i can just kind of deploy my thing 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 just i've just been using like aws because i had loads of credits uh 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 and it supports chris oliver's brilliant uh hatchbox so happy to hand him in money you know so that kind of interesting but kamal yes 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 yep i'm a big fan of render.com they're a bit expensive but uh in terms of like ease of deployment i just uh i find it to be heroku but for 2024 right yeah seems to be pretty popular
But yeah, I was just driven by, you know, if you go to AWS and you kind of go, yeah, here's my startup, you can get like two years of all these credits, great. I mean, it's a complete bait and switch thing from them, but actually pretty good. So you can kind of, you know, I think I got like a thousand bucks, kind of goes a long way, you know, it's great. But yeah, ultimately would I do that?
Maybe not, maybe render. Yeah, looks pretty cool.
Cool. Well, let's go ahead and switch gears and do picks, and then we'll wrap up. Ayush, do you want to start us off with picks?
Yeah, easy one this week. Haggis Ruby, new conference in Edinburgh on the 24th of October. Both Oli and I are speaking, so come for his talk, stay for mine. what else is there anything else I'm about to re-watch the big short with my friend this evening so non-tech big short if you haven't seen it go watch it yeah I think don't think about anything else today awesome Valentino what are your picks
I've been working on this fun project called Podcast Buddy. He's actually listening right now. It's an 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 not polished, but 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 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. 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 LeRobot where they're building a robot arm that... has like a trainable robot arm that comes with that you can 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, train a robot arm to do different things in my office. So we'll see how it goes.
Very cool. um i'm gonna jump in with some picks um i always do a board game pick first um i i would sometimes get long-winded so i'm gonna try and make this brief um i'm gonna pick challengers and i think i've picked this before but challengers is effectively like war and capture the flag um 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. Um, when you lose the flag, then your cards go onto your bench. 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. Um, And then you play seven rounds. You rotate between the other players.
It'll play up to eight people, right? So you have four simultaneous matches going on at the same time or three or two or whatever. If you have an odd number of people, there's a robot deck that kind of gets harder to beat 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, um, with the robot, uh, board game geek rates it at, or weights it at 1.78, which means it's pretty easy for casual gamers. Um, And it's eight 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 Frazella. 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 75 days. And it walks through the whole program. Anyway, it's awesome. So, you know, 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 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 going to pick that, too. Oli, do you have some picks for us?
Sure. Well, I'm going to big up Friendly RB, which takes place in September 18th, 19th, I think, in Bucharest, Romania. 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 there's still some tickets left. 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 big up that. What else? I had this kind of, 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 has passed me by a bit, but I kind of really like it. So I should probably be on Mastodon tonight, don't you think?
That kind of passed me by, but Big Up Blue Sky, go and check that out. I think it's quite interesting what they're doing. But I was going to say, I don't know if this is going to go out after the weekend, probably. So it might be too late for people at the Edinburgh Festival, but I saw this show the other day called Sawdust Symphony, which was one of the most incredible things.
I've seen some crazy stuff at the Edinburgh Fringe, but this was on another level. The way they pitch it is carpentry meets circus, carpentry And it's like three German guys for an hour on the stage doing things with wood and the whole stage, 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. Honestly, I've never seen anything like it in all my years. And I have a lot of years under my belt these days. So that would be mine.
This looks incredible. Thank you.
If people want to connect with you, how do they find you on the internet?
Yeah. I would say on Twitter, but not anymore. I go to a website, heady.net, and that has my links. I'm on Blue Sky and Threads, kind of, trying to say hello. Instagram...
uh or just email me i'm just ollie at hey.com uh so yeah that's how to find me but hidi.net is my kind of home i suppose on the internet with my blog and stuff like that awesome well thanks for coming this has been great a lot of fun thanks for having me yeah we'll wrap it here till next time max out