Speaker 1: Hey, folks, Welcome back to another episode of the Ruby
Speaker 1: Rogues podcast.
Speaker 2: This week, on our panel we have Ayushnwatya Hello.
Speaker 3: Hello.
Speaker 1: We also have Valentino Stole and now Charles max Wood
Speaker 1: from Top End Devs, and we have a special guest
Speaker 1: this week and that is Allie Heady.
Speaker 2: Ohhdi actually HEDI no, it's it's fine.
Speaker 1: I should have asked, but I assume because I think
Speaker 1: I'm smart, and then I screw stuff up because I
Speaker 1: think I'm smart. Anyway, do you want to just you
Speaker 1: were mentioning before the show you've worked at thirty seven Signals.
Speaker 1: You were the CTO for a free Agent, which is
Speaker 1: a bookkeeping and financial app for businesses. What else is
Speaker 1: there to know? What else are you famous for?
Speaker 3: I think I think you've done it really well for
Speaker 3: a sight of my famous I don't think so. But
Speaker 3: they're the two main things, really, I mean, free Agents,
Speaker 3: you know, consumed fifteen years of my life, so you
Speaker 3: know that that's pretty much most most things. Before that,
Speaker 3: I was a software developer, you know, nothing out of
Speaker 3: the ordinary, you know, started in the nineties. I used
Speaker 3: to do computer games originally when they came on CDs
Speaker 3: and had sprites that kind of game. And then yeah,
Speaker 3: I was that was my first job. I was just
Speaker 3: a programmer, writing to see the plus plus and yeah,
Speaker 3: making characters move on the screen. So that was kind
Speaker 3: of interesting, although quite hard work. Have to say, I wouldn't,
Speaker 3: you know, if you just want a nine to five,
Speaker 3: I wouldn't recommend video games.
Speaker 2: Video game developer.
Speaker 3: So yeah, I mean, great fun. I mean, to be honest,
Speaker 3: probably quite different in the nineties. I have no idea
Speaker 3: what it's like today. I'm not really in there. But
Speaker 3: but yeah, and then, you know, doing a variety of
Speaker 3: different jobs, and ended up being a being a kind
Speaker 3: of consultant, you know, going into banks, kind of soul
Speaker 3: destroying that kind of thing. And then yeah, and then
Speaker 3: we had It's funny because we had I had this
Speaker 3: accountant to do my you know, to do my books,
Speaker 3: had a limited company, and he used to send a
Speaker 3: spreadsheet every month and say fill this in, you know,
Speaker 3: so okay, and so I had to fill in all
Speaker 3: the bank transactions manually and then all the expenses and
Speaker 3: then send it back over and then and then he
Speaker 3: would do whatever he did and then said, well you
Speaker 3: wrote with this much tax, pay it here. So I
Speaker 3: had no idea about how financed, about the finances, how
Speaker 3: it all worked for anything, and it just felt like
Speaker 3: a bit of a waste of time. And you know,
Speaker 3: so as it turned out, Ed, who was another co
Speaker 3: founder ere Agent, he had he had the same accountant
Speaker 3: and he'd been you know, he'd started work on this
Speaker 3: prototype of free Agent using Ruby because that was super
Speaker 3: cool right in two thousand and six. That was the
Speaker 3: real hot tech. And I met and I met ed,
Speaker 3: and you know, we kind of got talking. Found this
Speaker 3: connection with our accountant and he was like, well, do
Speaker 3: you want to kind of help me build it? It was
Speaker 3: good and then quit my job and that was that.
Speaker 3: So that's kind of how it came about. And yeah,
Speaker 3: fifteen years later, kind of I left because we did
Speaker 3: an IPO in twenty sixteen on the London Stock Exchange
Speaker 3: and then and then we actually got acquired by a
Speaker 3: bank in twenty eighteen and so kind of stayed there
Speaker 3: for a little while after that, but then yeah, left
Speaker 3: in twenty twenty two. So that was the kind of
Speaker 3: the big startup journey of free Agent and Rails all
Speaker 3: the way Ruby and Rails. That was pretty much everything
Speaker 3: the whole that pretty much. Not not quite but pretty much.
Speaker 4: Was it hard to let it go?
Speaker 3: Let it go? Well, I mean yeah, yes, and no,
Speaker 3: I think yes, And that it's that it gives you
Speaker 3: that sense of identity, you know, and so you sort
Speaker 3: of lose this whole thing. It's like, yeah, the co founder,
Speaker 3: Well you can always say co found the company, but
Speaker 3: you know, you can't really you're detached from it then.
Speaker 3: But then but then not really because you know, I
Speaker 3: think it had for me, I felt like we'd almost
Speaker 3: built everything in it, Like every feature was kind of
Speaker 3: done in my mind, like it did everything from like
Speaker 3: time tracking all the way through to kind of filing
Speaker 3: your tax returns automatically. But at that point it's we
Speaker 3: kind of you know, felt like a kind of done.
Speaker 3: That's what we set out to do back in the day,
Speaker 3: and you know, I thought we'd never get there, but
Speaker 3: we did. And yeah, and the last thing we did
Speaker 3: was this massive migration of the infrastructure too, to the cloud.
Speaker 3: Not none of this cool, we move out of the cloud.
Speaker 3: We'd run the whole thing on servers, our own service
Speaker 3: for years, and then in twenty twenty, we we did
Speaker 3: the help. We did that, we moved to the cloud
Speaker 3: a WS and that was a big thing, and did
Speaker 3: you know for us was a good thing. Yeah. So
Speaker 3: once that was done, I was like, yeah, I think,
Speaker 3: I'm I think I'm kind of done here, but I
Speaker 3: do miss it. I still use it as well because
Speaker 3: I haven't. I do my own kind of consulting thing
Speaker 3: now and again, and I'm still used to age. I
Speaker 3: mean there quite often. It's good.
Speaker 5: Yeah, I'm a customer and I just love it because
Speaker 5: I'm completely technical. Book keeping, accounting stuff is just so
Speaker 5: i alien to me and I can just click around
Speaker 5: and learn stuff from from free agent. So it's been
Speaker 5: a boon for me as a freelancer to have that. So, like,
Speaker 5: what was the motivation behind going to the cloud because
Speaker 5: obviously with thirty seven signals all the ages going the
Speaker 5: other way?
Speaker 3: Yeah, absolutely, HH made Kamal so that he could get
Speaker 3: off the cloud. Yeah, it is a good question. So,
Speaker 3: I mean, I guess for starting, I am a big
Speaker 3: fan of running your own hardware in many ways, because
Speaker 3: you know, that's what we started doing. It was kind
Speaker 3: of the only option back in twenty sixty seven. I mean,
Speaker 3: you know, we just rented a server from rack space
Speaker 3: and that was kind of that and you know, and
Speaker 3: we did use there was all these cloud Easy two
Speaker 3: sort of existed, but early days, you know, it wasn't
Speaker 3: much tooling around that, and there were things like flight
Speaker 3: hosts and these other cloud bright Box, a few of
Speaker 3: these things that we did play around it just for
Speaker 3: staging servers, playing around, but the actual app ran on.
Speaker 3: It ran its own hardware, and we did at one
Speaker 3: point rax Space had a cloud and because we were
Speaker 3: in raxplace, let's let's use that. This would be great.
Speaker 3: But we found it really flaky. It was pretty unreliable
Speaker 3: for us, and we lost a bit of trust. And then,
Speaker 3: you know, one of the guys that we had on
Speaker 3: the team was was just great at building servers and stuff,
Speaker 3: networking and whatnot. So we just decided, well, let's just
Speaker 3: let's just do it, and we just we just bought
Speaker 3: some hardware and rap and racked it up and did
Speaker 3: all that and that's how it ran for well what
Speaker 3: would that be about nine years? But I suppose one
Speaker 3: of the big drivers was the tech we were using
Speaker 3: was kind of niche. We were using towards the end
Speaker 3: uh smarter s, which you may or may not have
Speaker 3: heard of. Not many people who heard of it which
Speaker 3: is basically like, ultimately it's Salaris, but it's an Loumoss
Speaker 3: And we were using Triton to do containerization and all
Speaker 3: of this. But it wasn't Docer, it wasn't Linux. It
Speaker 3: was kind of Niche worked really well, but actually the
Speaker 3: ops team we'd struggled to hire people to do it
Speaker 3: for that reason and also didn't necessarily want to do
Speaker 3: it as well most people, so it was a little
Speaker 3: bit troublesome. And obviously the cloud had come a long way,
Speaker 3: which we were already using. We already were using S
Speaker 3: three like all the rescipts, everything that you can helploaded free,
Speaker 3: it's all in stary. And that was always the case
Speaker 3: because you know, you don't want to be getting into
Speaker 3: objects storage yourself really and we'd already we were starting
Speaker 3: to do some data science stuff in AUS and so
Speaker 3: you know a lot of that stuff. It kind of
Speaker 3: made sense to us, well let's just think about moving
Speaker 3: the app over how you know, how hard can that be?
Speaker 3: And are lots of advantages And because we've been brought
Speaker 3: by a bank, they were they were kind of big
Speaker 3: on on the cloud as well, and they also had
Speaker 3: quite a lot of leverage with a US in terms
Speaker 3: of the white costs and stuff, so we could kind
Speaker 3: of pigedback on some of that. So all of that
Speaker 3: coming together really helped. And yeah, it was it was
Speaker 3: a good move for US, I think. I mean, cost wise,
Speaker 3: very hard to compare. I mean maybe maybe it's more depensive.
Speaker 3: I mean it's apples and oranges really when you're trying
Speaker 3: to compare these costs. But you know, the OPS team
Speaker 3: getting into kind of the infrastructure automation, infrastructure's code that
Speaker 3: which we already did. We were using Poppet and other
Speaker 3: technologies that we you know, kind of moved over to
Speaker 3: terra Form and all of this, which was much more.
Speaker 3: People wanted to work with this stuff, right, it was
Speaker 3: kind of like reasonably new hot tech that people wanted
Speaker 3: to do. And so yeah, it was. It was actually
Speaker 3: a pretty good move, I think. But I do I
Speaker 3: do kind of miss the power that you get from
Speaker 3: your own hardware. It's got, it's got. It's got to
Speaker 3: be said. To these databases on like Aurora, and you
Speaker 3: get these kind of I don't even know what they're called,
Speaker 3: you know, the xx sales or whatever, crazy prices really
Speaker 3: to be honest, but you know, as long as you
Speaker 3: can afford it, and it's you know, it fits within
Speaker 3: your budget and what you want, you're willing to pay
Speaker 3: in terms of you know, your margins, then it's fine.
Speaker 3: But if you're trying to squeeze, you know, squeeze margins,
Speaker 3: improve prove things, then sure. But we were optimizing really
Speaker 3: for a big engineering team. We had one hundred plus people,
Speaker 3: not very big oppostion, and you had about five people
Speaker 3: doing all of that, which is about half the size
Speaker 3: of thirty somethings. So, yeah, I think that answer your
Speaker 3: question a bit of a rambo.
Speaker 5: No, that's that's a very parol. And so yeah, you
Speaker 5: left in twenty twenty two, and then you did you
Speaker 5: go immediately do Patty sound signals after that?
Speaker 3: Yeah? It was, I mean I hadn't, I didn't intend
Speaker 3: to do. That was because I knew I was leaving
Speaker 3: free Agent. And at the time there were a couple
Speaker 3: of guys that had worked at free Agent that had
Speaker 3: gone there. They've gone they joined in like the summer
Speaker 3: of that year twenty one, and you know, I've seen
Speaker 3: touch these guys really great, great programmers, you know, fantastic people,
Speaker 3: and at the time they they were looking for like
Speaker 3: a director of engineering. And I think one of these
Speaker 3: guys said, you should talk to Ollie. You know, he's
Speaker 3: leaving leaving free Asian, maybe he'd be interested. And so
Speaker 3: it was kind of like a recommendation that happened. And
Speaker 3: then you know, I got the I got a call
Speaker 3: from David and so that you want to try about this,
Speaker 3: and you know, one one thing led to another, and
Speaker 3: I was like, this sounds pretty cool. And because quite
Speaker 3: a few people from free Agent when I when I
Speaker 3: then joined, I joined in March twenty two. By that
Speaker 3: point they'd hirde about. I think there was five people
Speaker 3: that were programmers and free Agents. It felt a bit
Speaker 3: like getting the gang back together together again. You know,
Speaker 3: I thought this would be quite cool. I can go
Speaker 3: and kind of work with these guys who were amazing
Speaker 3: and and you know, get to work with study sent things.
Speaker 3: That sounds brilliant.
Speaker 5: And then yeah, the reason I asked about the timing
Speaker 5: was because I was curious about did you just help
Speaker 5: free Agent get onto the cloud then switch jobs and
Speaker 5: help another company get off the cloud?
Speaker 3: Certainly doesn't look like that, doesn't it. But yeah, I think, well,
Speaker 3: my involvements in the in the cloud exit things was
Speaker 3: pretty minimal. I mean to be honest, I wasn't involved
Speaker 3: technically really in many things there it was. It was
Speaker 3: very much more of a management leadership role. So unfortunately,
Speaker 3: I think get stuck in fair enough.
Speaker 5: So I'm not saying there's just a blow smoke up
Speaker 5: her ass, but free Agent has one of the best
Speaker 5: webu eyes of more modern software as a service app
Speaker 5: that I've used and as chatting with other free Agent
Speaker 5: guys that at Brighton Ruby a couple of months ago
Speaker 5: and have said this to them as well. I'm curious
Speaker 5: from your point of view as a leader, because you
Speaker 5: grew the company through the twenty tens, how did you
Speaker 5: avoid this whole hype cycle of React and stuff? And
Speaker 5: because because the way I see it, most web YOUU
Speaker 5: eyes are shipped because people use React and shoved it
Speaker 5: where it has no business being. It's a great tool
Speaker 5: for the right job, but obviously i'll avoid the right now.
Speaker 5: But so how did you avoid the hypees and just
Speaker 5: keep things simple and as such? Like a very it's
Speaker 5: got a very snappy UI.
Speaker 2: Yeah, Ali, how are you such a genius?
Speaker 3: Well, I'd love to claim that, but let's let let's
Speaker 3: dive into what what the reality under the hood show?
Speaker 3: So I mean front end right, like back in two
Speaker 3: thousand and seven, the naughts, it was all you know, uh,
Speaker 3: prototype JS that kind of thing, right the job.
Speaker 2: Oh you're going way back.
Speaker 1: How it was that when I got started, Yeah, it
Speaker 1: was prototype, and then Jaquery was like the dream.
Speaker 3: Yeah we didn't have Jery but and so I suppose
Speaker 3: fortunately in some way, we just didn't really do that
Speaker 3: much javascripts, Like I think the only places we really
Speaker 3: had it were populating combo bot is that kind of thing,
Speaker 3: you know, when you change one, the next one populates
Speaker 3: a few things like that. So we kind of avoided
Speaker 3: it just because well, I wasn't really very good at joscript.
Speaker 3: I don't it. I am very good at joscript even now,
Speaker 3: to be honest, because I'm just trying to touch a
Speaker 3: voice it as much as I can. And then you know,
Speaker 3: jay Query, I guess came along and we used some
Speaker 3: of that for a while. And I think part of
Speaker 3: the thing was that free Agent's scope was really broad.
Speaker 3: So when it came to dev that there were so
Speaker 3: many features that we wanted to do, and it was
Speaker 3: like everything It's like payroll and you know bank you know,
Speaker 3: using bank feeds like Yoadley we had to do. Back
Speaker 3: in the day, there was this huge scope of stuff,
Speaker 3: so like fattening around and rewriting UI's was not really
Speaker 3: a useful business thing to do, so we just kind
Speaker 3: of didn't do it. We just left it now, except
Speaker 3: that one of the most kind of interactive parts of
Speaker 3: the app is the banking area, where you have all
Speaker 3: your bank transactions and you kind of click and you
Speaker 3: can explain them and categorize them. Now that probably twenty
Speaker 3: we're trying to think thirteen or something like that, I
Speaker 3: think someone had started playing around with a JavaScript framework.
Speaker 3: I can't remember off the top of the head actually
Speaker 3: what that was called. It was, it was one of
Speaker 3: the early ones, and then which I think we actually
Speaker 3: put live perhaps, But then someone during one of our
Speaker 3: hack days decided to try and build it and react
Speaker 3: the banking section which kind of works, and they got it.
Speaker 3: They've got it working quite quickly in a few days,
Speaker 3: you know, prototyping this thing, and it looked it was better,
Speaker 3: it worked better from a UI point of view, But
Speaker 3: then what it kind of grew arms and legs, and
Speaker 3: what happened with that project. Is that ultimately that area
Speaker 3: then became written in React and it stuck. Even though
Speaker 3: it was it was much more complicated. It's quite buggy
Speaker 3: because like all the validation that you know was in
Speaker 3: was on the server side, so all the front endfaltation
Speaker 3: was being duplicated again, including we had stuff like formatting
Speaker 3: numbers and stuff that the Rails Act would do, and
Speaker 3: so when this section got built in React, then all
Speaker 3: of that had to be people duplicating number formatting. So
Speaker 3: it's all a bit of a bit of a mess,
Speaker 3: to be honest, And as far as I know that
Speaker 3: is still there, that whole banking area in free agent
Speaker 3: is React. Well inside the kind of main frame, there's
Speaker 3: not so much sing. But but then honestly, I now
Speaker 3: it could be I could be slightly wrong here because
Speaker 3: it's going back to yours. But then so everything else
Speaker 3: kind of stay the same. And because the reacting took
Speaker 3: so long and in my opinion was a bit it's
Speaker 3: protracted and didn't really result in any any kind of
Speaker 3: great value, then nothing. We kind of made the call
Speaker 3: like nothing else and we forget about it. We're just
Speaker 3: going to leave it as it is and gradually improve things,
Speaker 3: by which point turbo and stimulus was coming along, and
Speaker 3: by the time I left then it was like, right
Speaker 3: that the future should be in We'll just stick with
Speaker 3: the rails conventions and we'll do stuff that way, ideally
Speaker 3: maybe replacing the whole reacting at some point. But again
Speaker 3: it's the same problem, like, well, there's lots of other
Speaker 3: things to do, what that kind of works, might as
Speaker 3: well leave it, even though you are juggling different technologies.
Speaker 3: So it's you know, we did, through general ignorance. We didn't,
Speaker 3: you know, rebuild the entire UAR in reaction. I'm quite
Speaker 3: thankful that we didn't. I think that would have probably
Speaker 3: been a bad idea. We did, we did have the
Speaker 3: mobile apses using kind of I don't think we used
Speaker 3: to reacting native, but I think we talked about doing that,
Speaker 3: but we ultimately just went with native. But yeah, so
Speaker 3: it's because of the size of free Agent. There's a
Speaker 3: lot of different tech going we did. I think we
Speaker 3: did get rid of j Query altogether eventually, but certainly
Speaker 3: even if base base camp still has j Query in parts,
Speaker 3: I'm pretty sure could be right, pretty sure it did
Speaker 3: as well, you know, because these things are quite hard
Speaker 3: to extract, it's it's a lot of effort and for
Speaker 3: pretty much zero user benefit pretty much, and they can work, right,
Speaker 3: So it's it's tricky managing things on that scale.
Speaker 5: I think, Yeah, I've never understood this whole thing of
Speaker 5: rewriting stuff that does the exact same thing but in
Speaker 5: a new stack. I'm like, what's the point of just
Speaker 5: just wasted effort? So yeah, let's just leave it, let
Speaker 5: it work.
Speaker 1: I generally agree, but if the ongoing maintenance burden will
Speaker 1: be lessened by rewriting it, and it's not like a
Speaker 1: total hey you're going to spend six months rewriting this piece, right,
Speaker 1: So you have to weigh all these things. But I've
Speaker 1: I've worked on apps where there was a new, better
Speaker 1: way of doing things.
Speaker 2: It was not terribly onerous to change it over.
Speaker 1: Yeah, there was no real benefit to the users except
Speaker 1: that the next time we had to come along and
Speaker 1: maintain touch and modify whatever that application stuff, it was
Speaker 1: going to be much much much easier, and so it
Speaker 1: allowed us to deliver better and faster in the future.
Speaker 4: I feel like too, you know, like a lot of
Speaker 4: people don't like they like to draw parallels of like
Speaker 4: front end coding to back end coding, and like you know,
Speaker 4: somebody wants to switch to rust, Like you know, that's
Speaker 4: a much steeper learning curve than just switching from j
Speaker 4: Query to react or something like that.
Speaker 3: Yeah, but I mean, I guess what's tricky as well
Speaker 3: when when you have a lot of engineers in a
Speaker 3: dozens and dozens of engineers, you get a lot a
Speaker 3: lot of opinions as to what is the right thing
Speaker 3: thing to do. And even when you know you're talking about, well,
Speaker 3: let's do will do stingulus, that's how we're going to
Speaker 3: do these things. You know, then you're going to people
Speaker 3: are going to say, well, great, can we use stimulus reflex?
Speaker 3: Can we do that because here's a good reason to
Speaker 3: use this, or you know, it's a challenge to kind
Speaker 3: of try and create standards which you ideally would like
Speaker 3: because then everything's the same as a level playing field.
Speaker 3: You all know what you're working on. But in reality,
Speaker 3: it's like if someone thinks they can do that under
Speaker 3: the benefit to doing that is is it bad? Is that? Dan?
Speaker 3: Just are you going to end up in situation where
Speaker 3: you're just using an obsolete technology and that you have
Speaker 3: to then replace or actually, is it fine. It's you're
Speaker 3: kind of making bets regardless of what you do, and
Speaker 3: sometimes you know the stimulus is good, isn't it? But well,
Speaker 3: in my experience, which isn't huge, to be fair, I
Speaker 3: think it's quite opaque in terms like exactly how to
Speaker 3: how what is the best practice? Like for an infinite scroll?
Speaker 3: I don't know, like if you google it, there's like
Speaker 3: loads of ways of doing it. Which way should I
Speaker 3: do it? And not a contrived example? Maybe that that
Speaker 3: kind of thing where it's where it's kind of, in
Speaker 3: my opinion, quite vague documentation about how to do stuff.
Speaker 3: You are kind of left to googling or chat GPT
Speaker 3: and hoping it comes back with stuff where and it's
Speaker 3: the same in the business, it's like, well, our only
Speaker 3: stimulus reflex is that bad? I'm just going to include
Speaker 3: this particular job script stuff and going to fit our
Speaker 3: needs here? Is that bad? Is that good? I kind
Speaker 3: of think it's okay, but I'll kind of keep an
Speaker 3: eye on it. Whereas we react. That's very much. It's
Speaker 3: a different paradigm, isn't it That that's much more complicated,
Speaker 3: I think where it's just a jobscript libraries.
Speaker 4: Career, So how do you assess like switching to new
Speaker 4: technologies or adopting new things, like what is your thought
Speaker 4: process on like doing that?
Speaker 3: I think my default is always why do we need
Speaker 3: to change anything? Can we just not? Because changing stuff
Speaker 3: is just like work and it's going to take longer
Speaker 3: than anyone says it will, and so can we do?
Speaker 3: You know? Can we just not? And there a lot
Speaker 3: of people, aren't there that still build stuff with J
Speaker 3: queer and stuff because it it just it works? Is
Speaker 3: that bad? Who's that guy on on X who's like
Speaker 3: the millionaire hacker guy, that nomadalist guy that levels Peter
Speaker 3: levels And I think he builds all of his stuff
Speaker 3: in PHP and JCO. Isn't you like you can can
Speaker 3: build anything with this stuff? So I think if you
Speaker 3: can resist, But then when you say you're resisting change,
Speaker 3: then you're kind of like an old dinosaur, aren't you?
Speaker 3: Don't you don't want to change? But the reality is this,
Speaker 3: when you're running a business, you just you do have
Speaker 3: to kind of focus mainly on customer value. And if
Speaker 3: it's not going to bring that value or maybe like
Speaker 3: increase den velocity by an order of magnitude or something,
Speaker 3: then do you really need to or is there If
Speaker 3: you are going to do it, then how can you
Speaker 3: do it incrementally? You know, how are you going to
Speaker 3: do that? And it's like if you want to go
Speaker 3: back to you know, turn everything into stimulus, that's great.
Speaker 3: Don't do the big stimulus projects. That's just going to
Speaker 3: take eighteen months by there. You know, like we're going
Speaker 3: to work on this banking area, let's just tackle that
Speaker 3: one while we're while we're in there. That that's more
Speaker 3: of the approach I would really take. I think, resist
Speaker 3: as long as possible until it became glaringly obvious that
Speaker 3: everyone's going to walk out, which is you know, not
Speaker 3: with our cloud stuff. You know, I don't think people
Speaker 3: are going to walk out. But I think if we
Speaker 3: really tried to keep forcing kind of smarter s, fighting
Speaker 3: down everyone's throat, I don't think it really ended well.
Speaker 3: We were going to have we had to do something there.
Speaker 3: But from a programming point of view, I'm not sure
Speaker 3: how common common that that problem is really. But you
Speaker 3: do tackle hard ones, you know, like a Ruby up grade.
Speaker 3: That what's good about things like that is that you know,
Speaker 3: you get the obsolescence, so you know that if you
Speaker 3: don't fix stuff by this date, then you're unsupported and
Speaker 3: you're you're you're in dangerous territory at that point. So
Speaker 3: that's quite nice when you have these actual So if
Speaker 3: someone said Jay career is getting turned off, not you
Speaker 3: can't really do that, but if they did, then maybe
Speaker 3: that would be a good a good thing to do.
Speaker 3: But yeah, but to try and simplify it as well, though,
Speaker 3: because that's always the challenge to try and keep the
Speaker 3: stack and and everything as simple as you can, which
Speaker 3: is which is hard, and it's something that thirty seven
Speaker 3: signals obviously do really well, but then they have fewer
Speaker 3: moving parts I think, you know, and and the invent
Speaker 3: all that stuff anyway, so it's kind of different.
Speaker 5: Yeah, the simplicity, the simplicity side of things is huge
Speaker 5: for me. And I also have like I have an
Speaker 5: allergy for dependencies. I hate pulling independencies. I just like
Speaker 5: I will need to have a really really good reason
Speaker 5: before I add something to my GEM file, Like it'll
Speaker 5: be like, literally, I do not want to solve this
Speaker 5: problem by myself, and that's when I'll pull in a
Speaker 5: GEM because I think most all the time you could
Speaker 5: just spend two or three yards and build something yourself
Speaker 5: that's specifically solves your problem, and it'll save you so
Speaker 5: much time in the long run because you don't have
Speaker 5: an external dependency that you don't control.
Speaker 3: Honestly, that's such good advice. I think, Yeah, we maybe
Speaker 3: didn't heed that. You know, there's always this tension, isn't it.
Speaker 3: You know, well, it's a bit like a build versus baring.
Speaker 3: Although it's open source, you're not really buying, you're just
Speaker 3: kind of borrowing. But yeah, when you come to do
Speaker 3: a Rails upgrade and you know that there's that one
Speaker 3: gem that you use so like tagging or whatever it is,
Speaker 3: there's some gem and it's just like, oh shit, that's
Speaker 3: unsupported for Rails six or you well, if you wrote
Speaker 3: your own, it's probably like a couple of classes and
Speaker 3: not very complicated. You could do that yourself. And that's
Speaker 3: something you know. Steady Send Signals do so well. Their
Speaker 3: gentiles are pretty small, really, whereas pretty sure Creator is
Speaker 3: pretty large. And it's definitely something I've taken on board
Speaker 3: a lot. I think that it is quite as good
Speaker 3: practice to try and minimize as much as possible, and
Speaker 3: I do remember it thirty seven singles when when they
Speaker 3: were starting on. I guess it was the calendar app
Speaker 3: and I think, you know, David's looking at these gem
Speaker 3: parts and basically, what why have we got REDDI? Why
Speaker 3: is reddis in there? And it ultimately led to kind
Speaker 3: of the solid cash and solid que stuff, which is
Speaker 3: just like, hang on, database, it really fast, but why
Speaker 3: don't need reddis. That's just a thing we just don't
Speaker 3: need and it's the thing we have to support, which
Speaker 3: ended up it's funny that ended up leading to these
Speaker 3: gems being built, like I'm sure they're fast enough. You know,
Speaker 3: the database is the fastest now on these new drives
Speaker 3: have just bought. We don't need reddis And it's almost like,
Speaker 3: I don't know where this is what was in David
Speaker 3: always like that. It was literally that dependency that was
Speaker 3: so irritating. They will just go and build all this
Speaker 3: new tech just because that is first great right, because
Speaker 3: one less dependency, Although have you because you've now got
Speaker 3: these highly complex gems. I don't know where it's red reliable.
Speaker 4: I'm curious on your thoughts about this idea, because like
Speaker 4: when I have a total agreement like let fewer dependencies
Speaker 4: the better, But at the same time, like some dependencies
Speaker 4: are like it's better to have a community building and
Speaker 4: identifying bugs and resolving features, Like what are your thoughts
Speaker 4: on that, Like how do you gauge like whether or
Speaker 4: not like community support around a certain feature set or
Speaker 4: technology or gem is like worth it over building it yourself.
Speaker 3: Yeah, I mean, for start, I suppose you have to
Speaker 3: have to look at the activity on it, don't you.
Speaker 3: If it's an active GEM then and pretty entrenched in,
Speaker 3: you know, in the community, and that's always a good sign.
Speaker 3: I don't think I would have I would hesitate really
Speaker 3: to use the GEM in that case, unless, as I say,
Speaker 3: it was so simple that you just think, well, do
Speaker 3: I really need to do that? You know, because sometimes
Speaker 3: they can complicate things and sometimes not. But the harder,
Speaker 3: I suppose, the harder the problem that you're trying to
Speaker 3: solve by using that GEM, then the more likely I
Speaker 3: would say it's probably better to use a GEM at
Speaker 3: least in the first instance. Right, And if if for
Speaker 3: some reason it gets unsupported or causes you performance problem
Speaker 3: or something, then then maybe maybe do it then. But
Speaker 3: if your goal is to move fast and just get
Speaker 3: stuff done, then you know, bring in device, right like
Speaker 3: most people do that I don't know Whereas you know,
Speaker 3: I built a couple of little apps recently, and as
Speaker 3: I'm not going to use device, I can do that myself.
Speaker 3: And I ended up doing my own off, which, for
Speaker 3: better or worse, you know, it didn't take that long.
Speaker 3: But at the same time, you know, it would have
Speaker 3: been much quicker to to use device. But you know,
Speaker 3: I just I don't know, I don't know what. But
Speaker 3: then I've had the same problem with apps where I've
Speaker 3: used device and then I've wanted to kind of rip
Speaker 3: it out because it was too painful to go into
Speaker 3: just that template of some password. I can't even remember
Speaker 3: the examples, but you know, some stort of that it
Speaker 3: shouldn't be that hard, and I thought there were certain
Speaker 3: things that I found hard. I'd rather just do my
Speaker 3: own kind of confirmation email sometimes. But then I guess
Speaker 3: it's also a balance of what. So it's what time
Speaker 3: you have available, what you kind of skill level is
Speaker 3: at some level, I suppose if you really don't want
Speaker 3: to get into that, then why bother. But if you
Speaker 3: if you're building a product and you know, like reagent
Speaker 3: or something that's things and maybe just kind of you
Speaker 3: do want to own that yourself, just in case device
Speaker 3: stops or if you know, deviates from what you need,
Speaker 3: or if you want to customize it, then maybe it's
Speaker 3: just a bit too hard. That kind of thing again.
Speaker 3: You know, another app I built, like Google Off, which
Speaker 3: I thought was going to be straight and straightforward. But
Speaker 3: that's my own naivety showing there, you know. But then
Speaker 3: I tried Omnios and that was there were certain things
Speaker 3: it was like outdate. It was a little bit a
Speaker 3: bit fiddly. So I think if you're a business and
Speaker 3: as well, yeah, I don't know. But if you if
Speaker 3: you're a business, you're making you're making money or you're
Speaker 3: well funded, then you know, maybe you should build your
Speaker 3: own if it's not going to be too onerous to
Speaker 3: do that, because then you own that tech and you
Speaker 3: can support it without question. But if you if you're
Speaker 3: the earlier day, or if you don't have that you
Speaker 3: know capacity, just use the gem and hope for the best.
Speaker 3: But think these things change. It's like active storage, you know,
Speaker 3: we used well originally at free agents. I think it
Speaker 3: was paper clip or something pretty good, and I think
Speaker 3: it's I can't remember. I think didn't it get it
Speaker 3: got support stopped but then we moved to Shrine, and
Speaker 3: then I think active storage appeared. But then I think
Speaker 3: we left it on Shrine, but then that now it's
Speaker 3: like you're using this unusual even though arguably Shrine is better.
Speaker 3: It's like most people don't know rather these active stories.
Speaker 3: But well, I'm glad you didn't build our own one
Speaker 3: of those to be To be honest, I think managing
Speaker 3: storage upload would probably have not been a great idea.
Speaker 3: I'd rather migrate from one to the other at that point.
Speaker 4: At least you're not someone like thought Bought that has
Speaker 4: like all of their clients using their thing and that
Speaker 4: they now have abandoned and have to upgrade everybody. I'm
Speaker 4: worried about that. But I'm curious, Like, so let's take
Speaker 4: a look at the dependency like aspect of things, like
Speaker 4: do you ever look at rails as like do I
Speaker 4: need reels like.
Speaker 3: Kind of thing?
Speaker 4: Because one thing I I've been to a lot of
Speaker 4: like you know, uh, non US based or European based
Speaker 4: Ruby conferences, it's like very much like absent.
Speaker 3: In those community rails.
Speaker 4: It's like not kind of like the preferred choice.
Speaker 3: It's like, as a web framework, what do you mean
Speaker 3: they're using what yeah, like you know just.
Speaker 4: Or like you know, some other web framework or just
Speaker 4: like Ruby specific app, like they're just running Ruby itself.
Speaker 4: Like it do you ever like think about whether or
Speaker 4: not like you need, you know, Rails for something new
Speaker 4: you're building, Like can this work as a spreadsheet or
Speaker 4: like is this better as a command line tool? Like
Speaker 4: do you ever look at other things? Or is it
Speaker 4: just like default at this point?
Speaker 3: I mean it's good question, but I suppose yeah, it
Speaker 3: depends what the problem the problem is. I mean for
Speaker 3: a web bat, I've just used rails. I mean you
Speaker 3: could say, well, it's quite a lot of baggage, isn't
Speaker 3: there is that? Sure you can write a track and
Speaker 3: a few files, but then the Rails app you're only
Speaker 3: really populating a few files. Like maybe you've got a controller,
Speaker 3: but at least it's pretty easy to find your way
Speaker 3: around smarter. Maybe maybe not. An active record is like
Speaker 3: baked in, and sure I can pull in active record
Speaker 3: or I don't know why I would bother doing that.
Speaker 3: I mean, maybe there's like an overhead and like memory
Speaker 3: or something. I don't really know. Maybe there's a thing there,
Speaker 3: who knows, But personally I would just use Rails. But yeah,
Speaker 3: command line apps, we would you know, not use Rails
Speaker 3: for that. I mean it depends like a phrase in
Speaker 3: one of the one of the one of one of
Speaker 3: the main things it does is like pdf of invoices,
Speaker 3: you know, and you can download PDFs, attach it to
Speaker 3: an email, all of that. And that's so that's the
Speaker 3: kind of thing that we wouldn't do in Rails because well,
Speaker 3: I think it's not quite it's not straightforward. It's so
Speaker 3: so we like had the Java thing that generated that,
Speaker 3: but Rails would call it so you know, it was
Speaker 3: the Rails app that was kind of talking just to
Speaker 3: an API to generate this dycipedia. So that kind of
Speaker 3: thing we wouldn't, you know, be fundamentalist, and it has
Speaker 3: to be in Ruby, has to be has to be
Speaker 3: in Rails. But just when when there's the best thing
Speaker 3: for the job that you would you would do use
Speaker 3: that if it's not too objectionable. But honestly, Rails, I
Speaker 3: don't know why they're not talking conferences that much about it.
Speaker 3: I mean I suppose what is that. Well, now you
Speaker 3: have Rails world now, right, so that's going to be
Speaker 3: all about Rails. So maybe the other conferences are a
Speaker 3: bit less of that, and it's interesting to hear different
Speaker 3: stories of what people are doing with Ruby that doesn't
Speaker 3: include Rails. I mean, you know, if you're working on
Speaker 3: a SAS app, that's kind of a big part of it.
Speaker 3: But then you know that people are doing like data
Speaker 3: stuff with Ruby, aren't they these days? I mean, I
Speaker 3: know Pythons like the the go to kind of language
Speaker 3: for that kind of stuff, but there are people trying
Speaker 3: to do stuff in Ruby, which I think is pretty cool,
Speaker 3: but I'm not Yeah, I wouldn't be from the mensalist
Speaker 3: about it if i'st building a way that I would
Speaker 3: just use. Rails just works right, it's great.
Speaker 5: It's just pulling on this dependency thread a little bit.
Speaker 5: More like going back to your authentication example, I do
Speaker 5: my own oth. I don't like device, I don't like
Speaker 5: pulling in anything to that. But the way I see it,
Speaker 5: once I've built it, once I can then I know
Speaker 5: this is blasphemous to some people who just copy paste
Speaker 5: the code into other apps and then tweak it as necessary,
Speaker 5: because sometimes you need to just tweak things a little bit,
Speaker 5: for like for the use case at hand is and
Speaker 5: once you have something working if you've written it well,
Speaker 5: that code should be reusable, I think. And that's something
Speaker 5: I kind of think about a lot. Is that trying
Speaker 5: to maximize the reusability of code that are not necessarily
Speaker 5: in a way that it can be extracted to a library.
Speaker 5: Because it's different when you've got god living in Europe
Speaker 5: and when you're kind of extracting something because then when
Speaker 5: you put it in the gym, it's more of a
Speaker 5: black box. But yeah, copy past good on the Once
Speaker 5: you solved the problem of authentication on your own, you know
Speaker 5: everything about how that code works, and you can just
Speaker 5: copy it into other projects. And what do you think
Speaker 5: about that kind of approach?
Speaker 3: Yeah, I mean that's that's kind of kind of happening.
Speaker 3: The apps that I built, one used Google off so
Speaker 3: that was slightly different, and then but the but the
Speaker 3: one used email authentication and one was used a password,
Speaker 3: so they're all they're all different for whatever reason, because
Speaker 3: of reasons. But but no, if I was I would
Speaker 3: probably do the same, I think. I mean, rails has
Speaker 3: baked into it, doesn't It has secure password stuff. It's
Speaker 3: kind of baked into it now, which is great, So
Speaker 3: it's pretty easy to do that. I suppose things like
Speaker 3: the forgot password is that boiler plate of stuff, but
Speaker 3: it's quite small. You really need to do kind of
Speaker 3: validate the email address and forget a password. That they're
Speaker 3: the things that I would need to do. But yeah,
Speaker 3: like I say, putting that in a gem, is would
Speaker 3: you do that? Because you're making assumptions about models and things.
Speaker 3: I guess you could do that, and that's what device
Speaker 3: has done, so maybe you should just use the device
Speaker 3: at that point. But then device quite big. He always
Speaker 3: feel quite big to me. But yeah, I suppose that's
Speaker 3: how I do it. But then but also what about
Speaker 3: when you know, because using names and passwords are unpopular
Speaker 3: perhaps these days. I mean, what I see using various
Speaker 3: apps around around the internet, you know is well to
Speaker 3: f A, right, like, how are you going to do that?
Speaker 3: And also are you going to do it with SMS
Speaker 3: email authent you know, one time passcodes and there doesn't
Speaker 3: always are you going to go with pass keys because
Speaker 3: that isn't the new thing, and it's I'm not sure
Speaker 3: I would do that myself, even to f A. You know,
Speaker 3: I don't know if you've done that yourself or not,
Speaker 3: or maybe I mean that's maybe something that rails can
Speaker 3: we'll get baked into it at some point. Maybe it's
Speaker 3: that's the trajectory it's going, or pass keys, maybe that'll come.
Speaker 3: That might be a good thing. I'm kind of surprised
Speaker 3: that it hasn't got rales, doesn't have a device it
Speaker 3: built in to be honest.
Speaker 5: Yeah, there's going to be something in railty. It's some
Speaker 5: kind of generator I think for that gives you a
Speaker 5: skeleton of authentication. And I think I remember seeing it
Speaker 5: tweets from DH like a couple of years ago that
Speaker 5: they might do something like similar to how secure password
Speaker 5: but for one time pass kis like, you know there's
Speaker 5: authenticator app. What's it called? Do dB? I think that
Speaker 5: based ones. Yeah, I think there's some I saw some
Speaker 5: chatter about like a has sick yere password flavor off,
Speaker 5: that kind of thing. I don't think anything's actually gone in,
Speaker 5: but yeah, it'd be good to have for show.
Speaker 4: Yeah, Dave action off too, that's pretty great.
Speaker 2: Yeah, action off is nice.
Speaker 1: That the thing is is that, you know kind of
Speaker 1: what I used just talking about. I've I've wanted something
Speaker 1: more like zero off, where essentially it is the generator
Speaker 1: that just sticks the code in.
Speaker 2: I mean, I've looked at the code for Action Off.
Speaker 1: It's it's pretty easy to follow, but yeah, it's still
Speaker 1: to me at least has that feeling of that black
Speaker 1: box where you know the zero authentication library. It there's
Speaker 1: no there's no engine, right, it just sticks the code
Speaker 1: in and then you can modify it until to make.
Speaker 2: It whatever you want.
Speaker 1: And that's kind of the thing that I really like,
Speaker 1: and so I'd love to see a lot of these
Speaker 1: common problems.
Speaker 2: In fact, I negotiated with Daniel Keho.
Speaker 1: I don't know if you guys remember him, but he
Speaker 1: had a series of rails apps that he had recorded
Speaker 1: videos of himself building way back in the day, and
Speaker 1: he had a project called Rails Composer, And essentially I'd
Speaker 1: asked you a bunch of questions and then populate your
Speaker 1: gem file.
Speaker 2: And yeah, that's my idea behind that.
Speaker 1: He gave me the domain and I want to just
Speaker 1: build a series of things like this, so it's like, hey,
Speaker 1: you have this common thing, and yeah, rather than have
Speaker 1: another gem added to your gem file, you literally have
Speaker 1: rails Composer in there in your development group, and then
Speaker 1: you just run the generators and it generates it and
Speaker 1: then kind of has the documentation in line like the
Speaker 1: rails stuff does that may point you out to videos
Speaker 1: that show you how to modify it to be whatever
Speaker 1: you want it to be, because I really and it's
Speaker 1: funny because initially I was gonna I was gonna do engines,
Speaker 1: and then I started reading Ayush's book and it walks
Speaker 1: you through building the authentication, and I'm like, this is
Speaker 1: just so much cleaner in so many ways, and I
Speaker 1: can make this into whatever I want.
Speaker 3: Right.
Speaker 2: It gives me the freedom to just do what I need.
Speaker 1: And so, yeah, I could give you all the pieces,
Speaker 1: it'll have a nice interface, it'll all be tailwind or whatever, right,
Speaker 1: but then you can just go in and modify it.
Speaker 1: So if you're using Bootstrap or something else, if you
Speaker 1: need it to do a couple of extra things, if
Speaker 1: you needed to trigger some jobs, well it generated the code.
Speaker 2: It's in your code. You check it in so you
Speaker 2: can change it anyway.
Speaker 3: Yeah.
Speaker 1: But I've been very inspired by this idea, Right, do
Speaker 1: I need a gem for this or not? Like I've
Speaker 1: been using friendly id for years and I figured out
Speaker 1: that about in about thirty lines of code, I can
Speaker 1: create a concern that I can pull into any model
Speaker 1: I want, right, and so then it's okay, So why
Speaker 1: am I using a GEM for this?
Speaker 3: Right?
Speaker 1: This is code I understand versus code I. I could
Speaker 1: go look at it. I'm sure it's relatively easy to
Speaker 1: follow along with. But yeah, then why do it the
Speaker 1: other way?
Speaker 4: Ollie? I'm curious, Like, you have a lot of experience
Speaker 4: in like product development and like the business focused aspect
Speaker 4: of like building things, right, so I'm curious like what
Speaker 4: your thoughts are on, like, uh, you know where the
Speaker 4: technology like is most helpful in the process in the
Speaker 4: business side or developing the product, and like why are
Speaker 4: you still sticking with rails at this point with all
Speaker 4: of the other stuff that's available. Is it familiarity or
Speaker 4: like where do you see like the technology really aligning
Speaker 4: with that aspect.
Speaker 3: Yeah, that's a good question, right, because well, I'm not
Speaker 3: kind of setting up a big SaaS business right right now.
Speaker 3: But if I was, what would I use use rails?
Speaker 3: I mean me personally, if I was like a founder
Speaker 3: founder CTO, again, I probably would maybe because that's like
Speaker 3: all I know, and I'm kind of institutionalized in rails, right,
Speaker 3: So there's that, But I still don't think it would
Speaker 3: be a bad choice. I think it would be a
Speaker 3: good choice because you know, as you know, you can
Speaker 3: build pretty much anything you need to with certainly good
Speaker 3: enough and certainly in the kind of B two B
Speaker 3: SaaS space of course like that which is you know,
Speaker 3: But that said, you know, it depends what you're building.
Speaker 3: If you're you know, if it's a consumer app, is
Speaker 3: are you going to be able to do what you
Speaker 3: need to do on the front end with with you know,
Speaker 3: rail stimulus? Is that is that you know good enough?
Speaker 3: Or do you do you actually need to lean on
Speaker 3: the community of more jobs script stuff, whether that's react
Speaker 3: or view or whatever else. I mean, you can still
Speaker 3: use rails on the back end, but are you then
Speaker 3: moving into a different architecture driven because of your needs
Speaker 3: on the front end. I mean, maybe that would be
Speaker 3: a different consideration. I think at one level, I honestly
Speaker 3: don't think it really matters because technology is not usually
Speaker 3: the thing that kills businesses. It honestly doesn't usually matter.
Speaker 3: Like the main problems with businesses are like a product
Speaker 3: market fit, Like you've built some in and no one
Speaker 3: wants it, or you've marketed it wrong, or you can't
Speaker 3: get the distribution that's usually the problem, not tech businesses
Speaker 3: that don't usually fail because someone picked rails or someone
Speaker 3: picked type scriptalk or whatever. That doesn't seem to be
Speaker 3: a pattern. So I don't think it really matters. But
Speaker 3: what I do think is interesting. So I do kind
Speaker 3: of talk to a lot of startups done some kind
Speaker 3: of like investing and stuff, but you know, and generally
Speaker 3: in the startup community and virtually non use rails. But
Speaker 3: in fact, maybe none that I've spoken to that is
Speaker 3: whereas reacts on the front end and something on the
Speaker 3: back end that is typically node type script. Maybe Python
Speaker 3: is the prevalent tech of today, which I find quite
Speaker 3: do quite find quite fascinating. But these teams move fast
Speaker 3: that they get stuff done. They you know, just like
Speaker 3: we do with rails, So you know, but it's arguably
Speaker 3: a bit more is it more complete? It feels more
Speaker 3: complicated to me. But then you know, at the same time,
Speaker 3: companies building on cloud tech as well, right, and they're
Speaker 3: just leveraging serverlus to do a whole manner of cool things,
Speaker 3: which you know, there are legit use cases for doing
Speaker 3: that kind of stuff. But at some level, I don't
Speaker 3: think it really matters. I think rails is still a
Speaker 3: brilliant choice. I would do that, but again that's because
Speaker 3: I'm probably institutionalized. But I wouldn't go and learn new
Speaker 3: tech just so I could build if unless it was
Speaker 3: for a specific advantage. You know, if you were doing
Speaker 3: some kind of AI stuff and you must use Python,
Speaker 3: then sure do that.
Speaker 4: Is there an example in rails where like you found
Speaker 4: that that feature being there just saved you a ton
Speaker 4: of you know, effort if you had gone with something
Speaker 4: else in the moment.
Speaker 3: It's a good question. I was doing some stuff earlier
Speaker 3: this year that did kind of touch on it. It
Speaker 3: was like it was to do with image categorization photographs,
Speaker 3: trying to kind of categorize photographs, and I did. I mean,
Speaker 3: I was using APIs to do that, like Microsoft API.
Speaker 3: They didn't support Ruby out of the box. They don't,
Speaker 3: you know, they have JavaScript. I can't remember, javscript, Python, Java,
Speaker 3: maybe maybe c Sharp maybe because it was Microsoft, can't remember,
Speaker 3: but that those are kind of the libraries, the SDKs
Speaker 3: that they offer. They don't offer Ruby, which is a shame,
Speaker 3: but there are there are gems that that kind of
Speaker 3: wrap this stuff up and and so that was quite
Speaker 3: that was quite interesting, but then some of the functionality
Speaker 3: that I mean, AI is not my not my thing really,
Speaker 3: but I was kind of toying around with this stuff,
Speaker 3: and Python does have a wealth of these libraries to
Speaker 3: do a lot of uh kind of machine learning algorithms,
Speaker 3: which Ruby doesn't really quite have. I mean that, I mean,
Speaker 3: there are people that are creating similar libraries out there
Speaker 3: for some of this stuff, but it's always feels, i
Speaker 3: don't know, not not quite not quite there. So from
Speaker 3: an AI point of view, depending if you're just calling
Speaker 3: a guys, of course, fine, you can do that from anything,
Speaker 3: but if you're then trying to do some stuff yourself
Speaker 3: using it, then it doesn't quite feel like the right choice.
Speaker 3: But maybe that's changing. It's only superficial knowledge that I
Speaker 3: really have of that, but I can't even really off
Speaker 3: the top of my head. Other other examples, I mean,
Speaker 3: there was this PDF thing that I mean that was
Speaker 3: a very good example where it just couldn't we're going
Speaker 3: to do like do it with prawn or something, where
Speaker 3: whereas you know, we we were using Java libraries that
Speaker 3: actually did proper PDF rendering. But you know, there were
Speaker 3: there were other ways we could have tackled that but
Speaker 3: we chose the the different tech path as opposed to
Speaker 3: finding a ruby a ruby way to do that. But
Speaker 3: I'm sure there are lots of other exams force. But
Speaker 3: you know, I think where Rails still seem to shine
Speaker 3: is when it's much more of a well people people
Speaker 3: come crud apps that they like, kind of it's kind
Speaker 3: of a bit demeaning. It's like the agent is a
Speaker 3: crud app. Yeah, I guess it's like, you know, it
Speaker 3: takes some input and you save it to a database.
Speaker 3: But at the same time, like, come on, there's like
Speaker 3: half a million lines of code doing lots of stuff.
Speaker 3: But I guess it's a cred app. You could say
Speaker 3: the same with you know, base camp as well app.
Speaker 3: Then what isn't notions of crud app? Isn't it? I
Speaker 3: don't know? So that's that's who knows, So like, hang on,
Speaker 3: that's everything at some level, isn't it top maybe chat,
Speaker 3: GPT or something, But we're not we're not building that.
Speaker 5: Yeah, most aps are crowd apps. I think it's just
Speaker 5: something people don't like saying. My client at the moment
Speaker 5: is actually is a startup and we're completely rails. So
Speaker 5: there is at least one startup, and I had briefly
Speaker 5: spoken to another startup a couple of months ago. I
Speaker 5: was working with them and they were going to be
Speaker 5: completely rails as well. The way I see, if there's
Speaker 5: something that you can't really do and Ruby or in Rails,
Speaker 5: it's usually something with quite a small footprinting, you could
Speaker 5: just extract that into its own service and build it
Speaker 5: using something else. So like like the PDF thing you said, so, yeah,
Speaker 5: you can't do that in Ruby, build that one tiny
Speaker 5: thing using something else and then just call it.
Speaker 3: Yeah, And I think that's entirely the right approach. But yeah,
Speaker 3: good to hear. There's you know, more startups that I mean,
Speaker 3: a lot of people building like indie hacks, which is
Speaker 3: kind of like another kind of really derogatory terms, but
Speaker 3: actually kind of that's where everything starts in a way,
Speaker 3: you know, using Rails. It's just you know, a lot
Speaker 3: that I've seen, so hopefully we'll kind of see. I
Speaker 3: think this is where like the Rails Foundation and does
Speaker 3: come into play. You know, there's a lot of money
Speaker 3: there and they're doing something cool stuff. There is obviously
Speaker 3: the conferences and the guide's looking a lot better now,
Speaker 3: But for me, it's like the outreach and how how
Speaker 3: can the Rails Foundation just get people an earlier stage
Speaker 3: in their career, I guess, and even boot camps and
Speaker 3: the rest of the rest of it to start using
Speaker 3: rails because boot camps did do rails back in the day,
Speaker 3: and now now they have tended to move from what
Speaker 3: I understand, it's more of a kind of a JavaScript ecosystem,
Speaker 3: which feels I don't know, I mean, to put yourself
Speaker 3: in the place of someone on a boot camp who
Speaker 3: doesn't know anything about programming, and all of a sudden
Speaker 3: you're like having to do like react sounds overwhelming to me,
Speaker 3: whereas at least with Ruby it's like kind of his
Speaker 3: I'll beat template and it's just basically HML. That feels
Speaker 3: a bit a bit less. But maybe when people go
Speaker 3: through these boot camps and do great so it could
Speaker 3: just be my own biases here that showing. But I
Speaker 3: think that's going to be an important part of Rail's
Speaker 3: future successes, that is to get in at the ground
Speaker 3: again and they make people realize how great it is.
Speaker 3: And I think, you know, that's part of the job
Speaker 3: of the Rails Foundation, but get everyone else shouting about
Speaker 3: it as well. Really so hopefully. I'm hopeful that this
Speaker 3: is this is already happening and we'll get better as
Speaker 3: well as people. Because there was a talk, wasn't there.
Speaker 3: It was it Irena from Evil Martians and she did
Speaker 3: a talk about startups on rails or something. I didn't
Speaker 3: see the talk, but I think I've seen the slides,
Speaker 3: and you know, she talks about some really interesting companies
Speaker 3: and companies that were built in other tech that are
Speaker 3: moving back to like a rails. We were all micro
Speaker 3: services and now we're going to come back to a
Speaker 3: railed monolist because frankly, it was just chaos and now
Speaker 3: this is far simpler and we didn't really need all
Speaker 3: of that complexity and distribution. We just needed an app
Speaker 3: with a big database and that goes a long way usually,
Speaker 3: So hopefully we'll start to see this change.
Speaker 5: Yeah, I think boot cans have just kind of generally
Speaker 5: moved away from teaching web fundamentals, like it'd be good, yeah,
Speaker 5: just have them go back to teaching literally the basics
Speaker 5: of web development, HTMLCSS, jamscript and obviously unbiased, but Ruby
Speaker 5: and rails. But because last year I helped out with
Speaker 5: the Rails World website, because the Rails foundation wanted a
Speaker 5: junior develop it, a build it, and they wanted someone
Speaker 5: to mentor the juniors. I helped that with the mentoring.
Speaker 5: And she was a boot camp graduate. She graduated from
Speaker 5: the Wagon quite recently, and they had a little bit
Speaker 5: of rare and quite a lot of react in the curriculum,
Speaker 5: if I remember correctly, and I remember showing her what
Speaker 5: you could do with just a customer element and JavaScript,
Speaker 5: and it was like, whoa, this is so easy. And
Speaker 5: it's like, yeah, I just wish bootcounts of beads that
Speaker 5: kind of stuff a bit more.
Speaker 3: Yeah, And like you say, you know, teaching jasket is
Speaker 3: super important. You have you have to kind of know drasket,
Speaker 3: but not necessarily a hugely complex level, you know, like
Speaker 3: you say, little sprint calls of the jasscript is often
Speaker 3: more than enough to accomplish what you need to do,
Speaker 3: and certainly at the boot camp level. But on the
Speaker 3: other hand, then there, you know, it's this chicken and
Speaker 3: egg problem that they're they're trying to get people jobs.
Speaker 3: That's that's what they're there for. And if and if
Speaker 3: all the jobs reacts, then it's their duty to then
Speaker 3: go and teach people what's going to get them most
Speaker 3: likely to get them the jobs so they can have their
Speaker 3: you know, placement stats nice and high. So it's it's
Speaker 3: a tricky one. You need the jobs that otherwise a
Speaker 3: boot camps might say, well, this will be no jobs
Speaker 3: in that, so why would we bother teaching it? And
Speaker 3: then you're on a bit of a downward spiral. So yeah, tricky.
Speaker 5: Yeah, it's also having a little bit of just shot down.
Speaker 5: It's a long time, Like, yeah, learning React, I'll get
Speaker 5: your job in the shot term, but then when React
Speaker 5: goes out of vogue, you won't have that foundation of
Speaker 5: basics to kind of fall back on and then learn
Speaker 5: something else. But that's a different discussion.
Speaker 3: I think, yeah, I think so it's pretty entrenched. I
Speaker 3: would say now I think pretty much, yeah, that's true
Speaker 3: here to stay sadly.
Speaker 2: Well, anything else that we want to dive into here which.
Speaker 3: We didn't touch on the old rail's assets, the original
Speaker 3: that you got in such about, I suppose.
Speaker 1: Yeah, we should, we should, we should definitely do that
Speaker 1: here for a minute, I actually am kind of curious
Speaker 1: about it.
Speaker 2: So I have to admit I haven't read the article.
Speaker 1: I didn't see that that was I'm working on a
Speaker 1: better system for letting us know what we need to
Speaker 1: read in order to prepare in the meantime. Yeah, you know,
Speaker 1: I think, well, actually, why don't you just give us
Speaker 1: the ten thousand foot view on what.
Speaker 2: The article is about and we can kind of attack.
Speaker 3: Yeah, of course. So it was one of those things
Speaker 3: where you know, I was ringing an ad and and
Speaker 3: loads to pay anything more than a need to absolutely
Speaker 3: minimum amount for a server to run to run this thing.
Speaker 3: And yeah, it's using active storage to store you know,
Speaker 3: uploaded content. But the particular apps that I was building
Speaker 3: involved customers uploading photos and dragging potentially hundreds small hundreds
Speaker 3: of photographs into a drop you know, drop zone thing
Speaker 3: and uploading the wall and then viewing these things in
Speaker 3: the app. So you can view you know, three four
Speaker 3: hundred photos in the gallery of course with like infinite
Speaker 3: scrolls on. But this is quite a lot of requests
Speaker 3: on the app when your images, you know, are in
Speaker 3: active storage. And you know, with my typefisted ways, I
Speaker 3: did you know that that's quite a lot of traffic
Speaker 3: in my app just on one page. It's a lot
Speaker 3: a lot of requests you know that I'm having to
Speaker 3: serve them. These images should really be on a cd N.
Speaker 3: Why are they even you know, the request should go
Speaker 3: directly to the cd and I don't want these requests
Speaker 3: hitting my app and that you know. So that's where
Speaker 3: that was where I started thinking, well, how do I
Speaker 3: solve this? How hard can it be? And well, it's
Speaker 3: not that hard, but it's it's quite convoluted like so,
Speaker 3: you know. But there were two there were kind of
Speaker 3: there were two related problems, which is slightly tangential. One
Speaker 3: one being Rail's assets, you know, the CSS and the
Speaker 3: JavaScript and whatnot. The other being the active storage images
Speaker 3: and solving those getting those onto a cd M. Two
Speaker 3: differ different problems that the assets approached well, and I
Speaker 3: was using cloud Front because I was on a w
Speaker 3: S and all the images are on in an S
Speaker 3: three bucket, so I thought, well, cloud Front's the obvious
Speaker 3: thing here that that must be pretty straightforward. But and
Speaker 3: I presume it's similar for other CDNs. I was just
Speaker 3: using cloud Front and had these three credits anyway, so
Speaker 3: you know, it might as well and configuring that and
Speaker 3: this wasn't really documented in in the Rails guides particularly
Speaker 3: kind of but not really, and so getting the assets
Speaker 3: on there was one challenge, which involves kind of trying
Speaker 3: to understand exactly, you know, how to configure cloud front
Speaker 3: and the BOOKHT and cause and this kind of stuff.
Speaker 3: And then the other was how to do the active
Speaker 3: storage assets particularly as well, and this is in a
Speaker 3: different use case but similar with action texts. Some were
Speaker 3: just active storage you know, has one attached, so just
Speaker 3: a file attached to multiple files attached to a model.
Speaker 3: The other being in action text you know, images that
Speaker 3: are inside an action text blocker, so indirectly active storaged
Speaker 3: on my model. And trying to solve that was kind
Speaker 3: of an interesting one as well, because you have to
Speaker 3: set up particular routing, direct routes to do this and
Speaker 3: involved environment variables and different you know, and understanding how
Speaker 3: to actually configure this cloud from the d N as well,
Speaker 3: which I have to say is is part mystery, Like
Speaker 3: I forgurt out how to make it work, but why
Speaker 3: specifically certain things I had to do when recommended configurations
Speaker 3: didn't actually work is still a mystery. And I wasn't
Speaker 3: that interested enough to actually go and understand exactly why.
Speaker 3: But I did document in this article like here's what
Speaker 3: I did, partly my own benefit because like, if I
Speaker 3: have to do this again, I'm literally never going to
Speaker 3: be able to understand what to do. Because it took
Speaker 3: me a while to figure it out because not that information,
Speaker 3: not that much information was out there, bits and pieces
Speaker 3: on the Rails forums and various blogs. But so I
Speaker 3: thought I'd try and encapsulate it. And it does seem
Speaker 3: to have worked because I have had a few people
Speaker 3: get in touch things. Thank you, Thank you for writing that,
Speaker 3: because I was banging my headgates a bit more trying
Speaker 3: to figure out how to make it work. So another
Speaker 3: thing I suppose that maybe the Rails could make a
Speaker 3: little bit easier, although it's quite complicated, all of this
Speaker 3: direct loads. If you look at the code in Rails
Speaker 3: for how how that works, it's quite it's quite hardcore
Speaker 3: in my opinion. So that's that's the sort of top
Speaker 3: that's that's where it came from and how I approached.
Speaker 4: It's kind of funny because we we talk about you know,
Speaker 4: your PDFs example, as being like a great use case
Speaker 4: for reels. I feel like files in general, like if
Speaker 4: you want to just like get a file upload working
Speaker 4: like Rails is great for that, but like if you
Speaker 4: want to cash it the right way. It's it's very complicated,
Speaker 4: but I feel like that's also true of anything, right,
Speaker 4: Like getting cloud Front looked up to any app in
Speaker 4: any language.
Speaker 3: Is a complex process.
Speaker 4: Like uh, and then how do you like, you know,
Speaker 4: what is the famous saying cash and bilidation is like
Speaker 4: one of the hardest, you know, naming and crashing validation.
Speaker 3: So I mean absolutely can't.
Speaker 4: Is there even a way to simplify this.
Speaker 3: Like, I mean, what what what? The correct thing I
Speaker 3: should have done, because it was a w S, was
Speaker 3: to kind of write that as code, you know, like
Speaker 3: here's a terraform script that will set up your you
Speaker 3: know right, I didn't do that. It probably slightly beyond
Speaker 3: me or beyond my patience. I should probably say I
Speaker 3: have this patients problem where I'm just in patience. So
Speaker 3: the correct thing would be just study the terraform and
Speaker 3: beautifully present this. You know, this is what I've got
Speaker 3: time for this. The crazy thing is O course out
Speaker 3: of time. I just choose not to. But yeah, I
Speaker 3: think that could that could help because then you're expressing
Speaker 3: in code exactly what you're doing on this on the
Speaker 3: cloud front and on the S three boocket. In the
Speaker 3: case of active storage. But on the rails side, I
Speaker 3: mean there's not that much to do. I mean, you know,
Speaker 3: once you're certainly with well with with the assets, there's
Speaker 3: virtually nothing to do. Just have to set the asset hopes.
Speaker 3: All the configuration is in in AS, where whereas with
Speaker 3: the active storage you have to create this direct route
Speaker 3: and then with that action text you have to then
Speaker 3: go and find the blog partial, you know, and go
Speaker 3: and change the route in the blog partial and things
Speaker 3: like that. But once than that, it's kind of straightforward.
Speaker 3: But it's yeah, fiddly, But I think that it's mainly
Speaker 3: fiddly because of the AS and if you if you
Speaker 3: could automate all that stuff yourself. But I suppose a
Speaker 3: good test would be to try on another CDN, which
Speaker 3: I have not done. You know, would it work on
Speaker 3: Digital Lotion or or some other you know, people have
Speaker 3: the other image media image specific CDNs than they especially
Speaker 3: on the on the larger side of if your app
Speaker 3: is you know, a big commercial app, you might not
Speaker 3: use Cloud from the tour. You might go for one
Speaker 3: of these proper image CDMs. How I have no idea
Speaker 3: whether that would be easier or more difficult, but ssumably
Speaker 3: from a Rails point of view kind of the same.
Speaker 3: You just have to get this route point to the
Speaker 3: right thing. So it's you know, it's it's more of
Speaker 3: an speak class problem, I would I would say than
Speaker 3: than Rails.
Speaker 1: Yeah, it's interesting too because you mentioned kind of the
Speaker 1: uploads and active storage. But one other thing that I
Speaker 1: thought about is just my pre compiled assets putting those
Speaker 1: on a CDN.
Speaker 2: For for a lot of the same reasons you mentioned.
Speaker 1: Right, you know, it's like, oh, you've got to pull
Speaker 1: up you know, maybe a couple of JavaScript files or
Speaker 1: my CSS or a bunch of images that you know,
Speaker 1: they're not active storage managed, they're just yeah, right.
Speaker 3: But yeah, that the as that one is pretty straightforward
Speaker 3: to do that. You just have to bake once you
Speaker 3: set up your clouds front instance and set the kind
Speaker 3: of core stuff, then then you just set that asset
Speaker 3: host in your Rails app and it like just works
Speaker 3: like it just it literally just works. And you know
Speaker 3: that none of those requests are now hit hitting your app.
Speaker 3: Every time you know, you deploy the cash, it gets updated.
Speaker 3: So yeah, it's it's great. Well to my knowledge that
Speaker 3: like that that's a big improvement. Hasn't had any issues
Speaker 3: that I'm aware of, you know, I mean clouds from
Speaker 3: pretty straightforward. At some level it works really well. Obviously
Speaker 3: you have to be what has been a ws for that,
Speaker 3: but I guess it helps if you're all in there.
Speaker 3: It would be interesting to know that, you know, if
Speaker 3: you're I don't know. It depends on what the thing is.
Speaker 3: This is another thing, isn't it like where where do
Speaker 3: people deploy their rails app? What's to go to thing?
Speaker 3: Because again nothing's perfect, but camal looks great to me.
Speaker 3: But then it's like, and I've got a database, what
Speaker 3: do I do? You know, It's like, you know, do
Speaker 3: I have to pay crunchy data now? And well if
Speaker 3: I do that, then what if my you know, my
Speaker 3: app is on Hetzner, But well do I now have
Speaker 3: to build? When do I run that in a Docker container?
Speaker 3: Do I? And that isn't that for me? That is uncovered?
Speaker 3: Whereas actually that's the most that's the most important thing.
Speaker 3: I don't really care about my web servers. It's my
Speaker 3: database that I care about. And you know, Heroka was good,
Speaker 3: but then they're kind of they're really tight fisted with
Speaker 3: the resources, which I don't like. But you know, so
Speaker 3: I don't know. That's another whole conversation, I guess, and
Speaker 3: that maybe for another time. But the definitive kind of
Speaker 3: I think commands going. I really like it. It's going
Speaker 3: in the right direction, but it doesn't quite get me
Speaker 3: what I want, Whereas like Digital Ocean, is it the
Speaker 3: app one, the docker base one that they have is
Speaker 3: really a good idea, but in practice hasn't in my opinion,
Speaker 3: hasn't been that. It's not a great It's slow, but
Speaker 3: conceptually it's great because you can get managed databases there.
Speaker 3: I can just kind of deploy my being by a
Speaker 3: Docker so that that seems great. But yeah, again there's
Speaker 3: quite fragmented where do you host. People have different opinions
Speaker 3: on that. Personally, I just I've just been using like
Speaker 3: a WUS because I had a loser credits and Hatchbox
Speaker 3: because it's just literally I don't even think about it.
Speaker 3: I just click a button and it works, which I
Speaker 3: think is great, and it sports Chris Oliver's brilliant Hatchbox.
Speaker 3: So happy to hand him money, you know, So that
Speaker 3: kind of interesting book camar If Hatchbox had Docker, then
Speaker 3: it would That's it is kind of like it's almost
Speaker 3: game over. At that point I think.
Speaker 5: But yep, I'm a big fan of render dot com.
Speaker 5: So they're a bit expensive, but in terms of like
Speaker 5: ease of deployment, I just find that to be heroical.
Speaker 5: But for twenty twenty four, right.
Speaker 3: Yeah, it seems to be pretty popular mm hm. But yeah,
Speaker 3: I was just driven by you know, if you get
Speaker 3: if you go to a WS and you kind of go, yeah,
Speaker 3: here's my startup. You can get get like two years
Speaker 3: of all these credits. Great. I mean it's it's a
Speaker 3: complete bait and switch thing from them, but actually pretty good.
Speaker 3: So you can kind of you know, I think I
Speaker 3: got like a thousand bucks, kind of goes a long way.
Speaker 3: You know, it's great. But yeah, ultimately would I do that?
Speaker 3: But maybe not? Maybe render? Yeah looks pretty cool. Cool.
Speaker 1: Well, let's let's go ahead and switch gears and do
Speaker 1: picks and then we'll wrap up.
Speaker 2: I usued. Do you want to start soft picks?
Speaker 5: Yeah?
Speaker 3: Easy one?
Speaker 5: This this week, I guess ruby uh new conference in
Speaker 5: Edinburgh in twenty four to October. Both Olie and I
Speaker 5: are speaking, so compare stark stay for mine, what else
Speaker 5: the theory else? I'm about to rewatch the big short
Speaker 5: with my friend This evening so non tech, big big short.
Speaker 5: If you haven't seen it, go watch it. Yeah, I
Speaker 5: think something about anything else today.
Speaker 2: Awesome, Valentino, what are your picks?
Speaker 4: I've been working on this fun project called podcast Buddy.
Speaker 4: He's actually listening right now, So AI companion that just
Speaker 4: lives in the terminal, and I can ask him questions
Speaker 4: right now, but I don't know what he'll respond with.
Speaker 4: So I'm gonna it's not polished, but he you know
Speaker 4: it just at the end of the episode here he'll
Speaker 4: create some show notes for us on what everybody's been
Speaker 4: talking about in nice organized format with links. So it's
Speaker 4: really fun. I use it for meetings to another version
Speaker 4: of it, I have a meeting Buddy, and it's just
Speaker 4: so much fun playing with Whisper and doing things locally
Speaker 4: with all these lms and audio.
Speaker 3: It's a lot of fun.
Speaker 4: So check that out Pop Buddy, And then I've been
Speaker 4: I found this. Somebody has this project called the robot
Speaker 4: where they're building a robot arm that has like a
Speaker 4: trainable robot arm that comes with that you can build
Speaker 4: with it to train it to do different things. And
Speaker 4: so somebody created a tutorial on how to do it all.
Speaker 3: And so I.
Speaker 4: Printed downloaded all the files and printed out all the parts,
Speaker 4: and I'll be building that just for kind of for fun,
Speaker 4: the train of robot armed to do different things in
Speaker 4: my office.
Speaker 3: So we'll see how it goes.
Speaker 2: Very cool.
Speaker 1: I'm gonna jump in with some picks. I always do
Speaker 1: a board game pick first. I always sometimes get long winded,
Speaker 1: so I'm gonna try and make this brief. I'm gonna
Speaker 1: pick Challengers, and I think I've picked this before, but
Speaker 1: Challengers is effectively like war and capture the Flag. So
Speaker 1: you flip cards over out of your hand until you've
Speaker 1: played more points than the top card of the other player,
Speaker 1: and then you get the flag, and then they do
Speaker 1: the same thing when you lose the flag. Then your
Speaker 1: cards go on to your bench. Once your bench is
Speaker 1: full and you can't place another card on it, your
Speaker 1: opponent wins, or if you run out of cards in
Speaker 1: your hand, your opponent wins, and then you play seven rounds.
Speaker 1: You rotate between the other players. It'll play up to
Speaker 1: eight people, right, so you have four simultaneous matches going
Speaker 1: on at the same time, or three or two or whatever.
Speaker 1: If you have an odd number of people there's a
Speaker 1: robot deck that kind of gets harder to beat as
Speaker 1: the rounds go on. But theoretically you're drafting cards and
Speaker 1: building your hand or your deck up, so your deck
Speaker 1: should be stronger and so you should be able to
Speaker 1: hold out with the.
Speaker 2: With the robot board game.
Speaker 1: Geek rates it at or weights it at one point
Speaker 1: seven eight, which means it's pretty easy for casual gamers,
Speaker 1: and it's eight and older can play it. So anyway,
Speaker 1: that's my board game pick. I just finished a book.
Speaker 1: It's the Book on Mental Toughness by Andy Frizella. You
Speaker 1: have to actually go to his website to get it.
Speaker 1: Walks through the seventy five Hard program, which I'm in
Speaker 1: the middle of right now. I'm Monday seventeen of seventy
Speaker 1: five days, and it walks through the whole program. It's
Speaker 1: it anyway, it's awesome. So you know, it's part physical health,
Speaker 1: part mental toughness, part other stuff.
Speaker 2: So go check that out for sure.
Speaker 1: He also has a podcast relaf which is worth checking out.
Speaker 2: And then.
Speaker 1: Part of the program too is you have to read
Speaker 1: ten pages out of a book every day, and so
Speaker 1: the book I'm reading now that I finish that is
Speaker 1: Awaken the Giant Within by Tony Robbins, and I am
Speaker 1: really in this book, So I'm going to pick that
Speaker 1: to you, Alie, do you have some picks for us?
Speaker 3: Sure? Well, I'm going to big up Friendly I'll be,
Speaker 3: which takes place in September eighteen nineteenth, I think in Bucharest,
Speaker 3: Romania and the whole I'm speaking there, but there's a
Speaker 3: whole bunch of much better speakers than me, which you
Speaker 3: should go and check out. I believe as orc some
Speaker 3: tickets left. I have a discount, but you have to
Speaker 3: I can't. I don't think I can announce that. You
Speaker 3: can to find me and if you want a discount,
Speaker 3: I can give you a discount to that. So I
Speaker 3: big up that. What else I had? This kind of
Speaker 3: I've been on Twitter for like well since back in
Speaker 3: the day, but yeah, I kind of I've been checking
Speaker 3: out Blue Sky lately, which I've passed me by a bit,
Speaker 3: but I kind of really like it, so I should
Speaker 3: probably be on Mastered on should not. I don't mean
Speaker 3: that kind of passed me by, but big up Sky,
Speaker 3: go and check that out. I think I think it's
Speaker 3: quite interesting what they're doing. But I was going to say,
Speaker 3: I don't know if this is going to go out
Speaker 3: after the after the weekend, probably so it might be
Speaker 3: too late for people at the Edinburgh Festival. But I
Speaker 3: saw this show the other day which called Sawdust Symphony,
Speaker 3: which was one of the most incredible things. I've seen
Speaker 3: some crazy stuff at Edinburgh Fringe, but this was on
Speaker 3: another level. It was the way they pitch it is
Speaker 3: carpentry meats circus and it's like three German guys for
Speaker 3: an hour on the stage doing things with wood and
Speaker 3: the whole stage show that including lathes and glue. It was. Honestly,
Speaker 3: it sounds ridiculous, but it's absolutely incredible. So I you
Speaker 3: could probably see some videos of it online saw Dust Symphony.
Speaker 3: I honestly I've never seen anything like it in all
Speaker 3: my years, and that I have a lot of years
Speaker 3: under my belt these days, so that would be my.
Speaker 4: This looks incredible.
Speaker 3: Thank you.
Speaker 1: If if people want to connect with you, how do
Speaker 1: they find you on the internet?
Speaker 3: Yeah, I would say on Twitter, but not anymore. I
Speaker 3: got a website, he do, and that has my links.
Speaker 3: I'm on Blue Sky and threads kind of trying to
Speaker 3: say hello Instagram or does it email me? I'm just
Speaker 3: Ali at hey dot com, so yeah, that's how to
Speaker 3: find me. But he dot is my kind of home
Speaker 3: I suppose on the Internet, of my blog and stuff
Speaker 3: like that.
Speaker 2: Awesome. Well, thanks for coming.
Speaker 3: This has been great, Thanks for having me.
Speaker 2: Yeah, we'll wrap it here until next time. Max out