Cloud Migration, Server Costs, and CDN Challenges - RUBY 650

I was that was my first job. I was just a programmer, writing to see the plus plus and yeah, making characters move on the screen. So that was kind of interesting, although quite hard work. Have to say, I wouldn't, you know, if you just want a nine to five, I wouldn't recommend video games.

destroying that kind of thing. And then yeah, and then we had It's funny because we had I had this accountant to do my you know, to do my books, had a limited company, 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, well you

wrote with this much tax, pay it here. So I had no idea about how financed, about the finances, how it all worked for anything, and it just felt like a bit of a waste of time. And you know, so as it turned out, Ed, who was another co founder ere 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 two thousand and six. That was the real hot tech. And I met and I met ed,

and you know, we kind of got talking. Found this connection with our accountant and he was like, well, do you want to kind of help me build it? It was good and then quit my job and that was that. So that's kind of how it came about. And yeah, fifteen years later, kind of I left because we did an IPO in twenty sixteen on the London Stock Exchange and then and then we actually got acquired by a bank in twenty eighteen and so kind of stayed there for a little while after that, but then yeah, left

in twenty twenty two. 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 that pretty much. Not not quite but pretty much.

But then but then not really because you know, I think it had for me, I felt like we'd almost built everything in it, Like every feature was kind of done in my mind, like it did everything from like time tracking all the way through to kind of filing your tax returns automatically. But at that point it's we kind of you know, felt like a 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. And yeah, and the last thing we did was this massive migration of the infrastructure too, to the cloud. Not none of this cool, we move out of the cloud. We'd run the whole thing on servers, our own service for years, and then in twenty twenty, we we did the help. We did that, we moved to the cloud a WS and that was a big thing, and did you know for us was a good thing. Yeah. So 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 haven't. I do my own kind of consulting thing now and again, and I'm still used to age. I mean there quite often. It's good.

of the only option back in twenty sixty seven. I mean, you know, we just rented a server from rack space and that was kind of that and you know, and we did use there was all these cloud Easy two sort of existed, but 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 it just for staging servers, playing around, but the actual app ran on.

It ran its own hardware, and we did at one point rax Space had a cloud and because we were in raxplace, let's let's use that. This would be great. But we found it really flaky. It was pretty unreliable for us, and we lost a bit of trust. And then, you know, one of the guys that we had on the team was was just great at building servers and stuff,

networking and whatnot. So we just decided, well, let's just let's just do it, and we just we just bought some hardware and rap and racked it up and did all that and that's how it ran for well what would that be about nine years? But I suppose one of the big drivers was the tech we were using was kind of niche. We were using towards the end uh smarter s, which you may or may not have

heard of. Not many people who heard of it which is basically like, ultimately it's Salaris, but it's an Loumoss And we were using Triton to do containerization and all of this. But it wasn't Docer, it wasn't Linux. It was kind of Niche worked really well, but actually the ops team we'd 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 S three like all the rescipts, everything that you can helploaded free, it's all in stary. And that was always the case because you know, you don't want to be getting into objects storage yourself really and we'd already we were starting to do some data science stuff in AUS 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 are lots of advantages And because we've been brought by a bank, they were they were kind of big on on the cloud as well, and they also had quite a lot of leverage with a US in terms of the white costs and stuff, so we could kind of pigedback on some of that. So all of that coming together really helped. And yeah, it was it was a good move for US, I think. I mean, cost wise, very hard to compare. I mean maybe maybe it's more depensive. 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's code that which we already did. We were using Poppet and other technologies that we you know, kind of moved over to terra Form 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. It was actually

a pretty good move, I think. But I do I do kind of miss the power that you get from your own hardware. It's got, it's got. It's got to be said. To these databases on like Aurora, and you get these kind of I don't even know what they're called, you know, the xx sales 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 margins, improve prove things, then sure. But we were optimizing really for a big engineering team. We had one hundred plus people, not very big oppostion, and you had about five people doing all of that, which is about half the size of thirty somethings. So, yeah, I think that answer your question a bit of a rambo.

guys said, you should talk to Ollie. You know, he's leaving leaving free Asian, maybe he'd be interested. And so it was kind of like a recommendation that happened. And then you know, I got the I got a call from David and so that you want to try about this, and you know, one one thing led to another, and I was like, this sounds pretty cool. And because quite a few people from free Agent when I when I then joined, I joined in March twenty two. By that

point they'd hirde about. I think there was five people that were programmers and free Agents. It felt a bit like getting the gang back together together again. You know, I thought this would be quite cool. I can go and kind of work with these guys who were amazing and and you know, get to work with study sent things. That sounds brilliant.

avoid this whole hype cycle of React and stuff? And because because the way I see it, most web YOUU eyes are shipped 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 right now. But so how did you avoid the hypees and just keep things simple and as such? Like a very it's got a very snappy UI.

voice it as much as I can. And then you know, jay Query, 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 that there were so many features that we wanted to do, and it was like everything It's like payroll and you know bank you know,

using bank feeds like Yoadley we had to do. Back in the day, there was this huge scope of stuff, so like fattening around and rewriting UI's 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 twenty we're trying to think thirteen or something like that, I think someone had started playing around with a JavaScript framework. I can't remember off the top of the head actually what that was called. It was, 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 and react the banking section which kind of works, and they got it.

They've got it working quite quickly in a few days, you know, prototyping this thing, and it looked it was better, it worked better from a UI point of view, But then what 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 it was much more complicated. It's quite buggy because like all the validation that you know was in was on the server side, so all the front endfaltation was being duplicated again, including we had stuff like formatting numbers and stuff that the Rails Act would do, and so when this section got built in React, then all

of that had to be people duplicating number formatting. So it's all a bit of a bit of a mess, to be honest, And as far as I know that is still there, that whole banking area in free agent is React. Well inside the kind of main frame, there's not so much sing. But but then honestly, I now it could be I could be slightly wrong here because it's going back to yours. But then so everything else

kind of stay the same. And because the reacting took so long and in my opinion was a bit it's protracted and didn't really result in any any kind of great value, then nothing. We kind of made the call

like nothing else and we 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, and by the time I left then it was like, right that the future should be in We'll just stick with the rails conventions and we'll do stuff that way, ideally

maybe replacing the whole reacting at some point. But again it's the same problem, like, well, there's lots of other things to do, what that kind of works, might as well leave it, even though you are juggling different technologies. So it's you know, we did, through general ignorance. We didn't, you know, rebuild the entire UAR in reaction. I'm quite thankful that we didn't. I think that would have probably

been a bad idea. We did, we did have the mobile apses using kind of I don't think we used to reacting 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 free Agent. There's a

lot of different tech going we did. I think we did get rid of j Query altogether eventually, but certainly even if base base camp still has j Query in parts, I'm pretty sure could be right, pretty sure it did as well, you know, because these things are quite hard to extract, it's it's a lot of effort and for pretty much zero user benefit pretty much, and they can work, right, So it's it's tricky managing things on that scale.

Can we do that because here's a good reason 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 as 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 under the benefit to doing that is is it bad? Is that? Dan? Just are you going to end up in situation where you're just using an obsolete technology and that you have

to then replace or actually, is it fine. It's you're kind of making bets regardless of what you do, and sometimes you know the stimulus is good, isn't it? But well, in my experience, which isn't huge, to be fair, I think it's quite opaque in terms like exactly how to how what is the best practice? Like for an infinite scroll? I don't know, like if you google it, there's like loads of ways of doing it. Which way should I

do it? And not a contrived example? Maybe that that kind of thing where it's where it's kind of, in my opinion, quite vague documentation about how to do stuff. You are kind of left to googling or chat GPT and hoping it comes back with stuff where and it's the same in the business, it's like, well, our only stimulus reflex is that bad? I'm just going to include this particular job script stuff and going to fit our

needs here? Is that bad? Is that good? I kind of think it's okay, but I'll kind of keep an eye on it. Whereas we react. That's very much. It's a different paradigm, isn't it That that's much more complicated, I think where it's just a jobscript libraries.

in PHP and JCO. Isn't you like you can can build anything with this stuff? So 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? Don't you don't want to change? But the reality is this, 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 den 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 you know, turn everything into stimulus, that's great. Don't do the big stimulus projects. That's just going to

take eighteen months by there. 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 would really take. I think, resist as long as possible until it became glaringly obvious that everyone's going to walk out, which is you know, not with our cloud stuff. You know, I don't think people

are going to walk out. But I think if we really tried to keep forcing kind of smarter s, fighting down everyone's throat, I don't think it really ended well. We were going to have we had to do something there. But from a programming point of view, I'm not sure how common common that that problem is really. But you do tackle hard ones, you know, like a Ruby up grade.

That 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 you're you're in dangerous territory at that point. So that's quite nice when you have these actual So if someone said Jay career is getting turned off, not you can't really do that, but if they did, then maybe that would be a good a good thing to do.

But yeah, but to try and simplify it as well, though, because that's always the challenge to try and keep the stack and and everything as simple as you can, which is which is hard, and it's something that thirty seven signals obviously do really well, but then they have fewer moving parts I think, you know, and and the invent all that stuff anyway, so it's kind of different.

allergy for dependencies. I hate pulling independencies. I just like I will need to have a really really good reason before I add something to my GEM file, Like it'll be like, literally, I do not want to solve this problem by myself, and that's when I'll pull in a GEM because I think most all the time you could just spend two or three yards and build something yourself that's 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.

kind of borrowing. But yeah, when you come to do a Rails upgrade and you know that there's that one gem that you use so like tagging or whatever it is, there's some gem and it's just like, oh shit, that's unsupported for Rails six or you well, if you wrote your own, it's probably like a couple of classes and not very complicated. You could do that yourself. And that's something you know. Steady Send Signals do so well. Their gentiles are pretty small, really, whereas pretty sure Creator is

pretty large. And it's definitely something I've taken on board a lot. I think that it is quite as good practice to try and minimize as much as possible, and I do remember it thirty seven singles when when they were starting on. I guess it was the calendar app and I think, you know, David's looking at these gem parts and basically, what why have we got REDDI? Why

is reddis in there? And it ultimately led to kind of the solid cash and solid que stuff, which is just like, hang on, database, it really fast, but why don't need reddis. That's just a thing we just don't need and it's the 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, the database is the fastest now on these new drives

have just bought. We don't need reddis And it's almost like, I don't know where this is what was in David always 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 first great right, because one less dependency, Although have you because you've now got these highly complex gems. I don't know where it's red reliable.

they can complicate things and sometimes not. But the harder, 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 if if for some reason it gets unsupported or causes you 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 device, right like most people do that I don't know Whereas you know, I built a couple of little apps recently, and as I'm not going to use device, I can do that myself. And I ended up doing my own off, 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 what. 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 into just that template of some password. I can't even remember the examples, but you know, some stort of that it shouldn't be that hard, and I thought 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. So it's what time you have available, what you 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 if you're building a product and you know, like reagent or something that's things and maybe just kind of you do want to own that yourself, just in case device stops or if you know, 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 again.

You know, another app I built, like Google Off, which I thought was going to be straight and straightforward. But that's my own naivety showing there, you know. But then I tried Omnios and that was there were certain things it was like outdate. It was a little bit a bit fiddly. So I think if you're a business and

as well, yeah, I don't know. But if you 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 if you're the earlier day, or if you don't have that you know capacity, just use the gem and hope for the best. But think these things change. It's like active storage, you know,

we used well originally at free agents. I think it was paper clip or something pretty good, and I think it's I can't remember. I think didn't it get it got support stopped but then we moved to Shrine, and then I think active storage appeared. But then I think we left it on Shrine, but then that now it's like you're using this unusual even though arguably Shrine is better. It's like most people don't know rather these active stories.

But well, I'm glad you didn't build our own one of those to be 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.

around smarter. 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 personally I would just use Rails. But yeah, command line apps, we would you know, not use Rails

for that. I mean it depends like a phrase in one of the one of the one of one of the main things it does is like pdf of invoices, you know, and you can download PDFs, attach it to an email, all of that. And that's so that's the kind of thing that we wouldn't do in Rails because well, I think it's not quite it's not straightforward. It's so so we like had the Java thing that generated that, but Rails would call it so you know, it was the Rails app that was kind of talking just to

an API to generate this dycipedia. So that kind of thing we wouldn't, you know, be fundamentalist, and it has to be in Ruby, has to be has to be in Rails. But just when when there's the best thing for the job that you would you would do use that if it's not too objectionable. But honestly, Rails, I don't know why they're not talking conferences that much about it. I mean I suppose what is that. Well, now you have Rails world now, right, so that's going to be

all about Rails. So maybe the other conferences are a bit less of that, and it's 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 SAS app, that's kind of a big part of it. But then you know that people are doing like data

stuff with Ruby, aren't they these days? I mean, I know Pythons like the the go to kind of language for that kind of stuff, but there are people trying to do stuff in Ruby, which I think is pretty cool, but I'm not Yeah, I wouldn't be from the mensalist about it if i'st building a way that I would just use. Rails just works right, it's great.

pulling in anything to that. But the way I see it, once I've built it, once I can then I know this is blasphemous to some people who just copy paste the code into other apps and then tweak it as necessary, because sometimes you need to just tweak things a little bit, for like for the use case at hand is and once you have something working if you've written it well, that code should be reusable, I think. And that's something

I kind of think about a lot. Is that trying to maximize the reusability of code that are not necessarily in a way that it can be extracted to a library. Because it's different when you've got god living in Europe and when you're kind of extracting something because then when you put it in the gym, it's more of a black box. But yeah, copy past good on the Once you 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. And what do you think about that kind of approach?

it's pretty easy to do that. I suppose things like the forgot password is that boiler plate of stuff, but it's quite small. You really need to do kind of validate the email address and forget a password. That 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 device has done, so maybe you should just use the device

at that point. But then device quite big. He always feel quite big to me. But yeah, I suppose that's how I do it. But then but also what about when you know, because using names and passwords are unpopular perhaps these days. I mean, what I see using various apps around around the internet, you know is well to f A, right, like, how are you going to do that?

And also are you going to do it with SMS email authent you know, one time passcodes and there doesn't always are you going to go with pass keys because that isn't the new thing, and it's I'm not sure I would do that myself, even to f A. 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 we'll get baked into it at some point. Maybe it's that's the trajectory it's going, or pass keys, maybe that'll come.

That might be a good thing. I'm kind of surprised that it hasn't got rales, doesn't have a device it built in to be honest.

that kind of thing. I don't think anything's actually gone in, but yeah, it'd be good to have for show.

you want it to be, because I really and it's funny because initially I was gonna I was gonna 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 in so many ways, and I can make this into whatever I want.

of the other stuff that's available. Is it familiarity or like where do you see like the technology really aligning with that aspect.

be a bad choice. I think it would be a good choice because you know, as you know, you can build pretty much anything you need to with certainly good enough and certainly in the kind of B two B 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, is are you going to be able to do what you need to do on the front end with with you know, rail stimulus? Is that is that you know good enough?

Or do you do you actually need to lean on the community of more jobs script stuff, whether that's react or view or whatever else. I mean, you can still use rails on the back end, but are you then moving into a different architecture driven because of your needs on 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.

Like the main problems with businesses are like a product market fit, Like you've built some in and no one wants it, or you've marketed it wrong, or you can't get the distribution that's usually the problem, not tech businesses that don't usually fail because someone picked rails or someone picked type scriptalk or whatever. That doesn't seem to be 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 and virtually non use rails. But in fact, maybe none that I've spoken to that is whereas reacts 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 do quite find quite fascinating. But these teams move fast

that they get stuff done. They you know, just like we do with rails, So you know, but it's arguably a bit more is it more complete? 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 serverlus to do a whole manner of cool things, 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 if unless it was for a specific advantage. You know, if you were doing some kind of AI stuff and you must use Python, then sure do that.

you know, they have JavaScript. I can't remember, javscript, Python, Java, maybe maybe c Sharp maybe because it was Microsoft, can't remember, but that those are kind of the libraries, the SDKs

that they offer. They don't offer Ruby, which is a shame, but there are there are gems that that kind of wrap this stuff up and and so that was quite that was quite interesting, but then some of the functionality that I mean, AI is not my not my thing really, but I was kind of toying around with this stuff, and Python does have a wealth of these libraries to do a lot of uh kind of machine learning algorithms,

which Ruby doesn't really quite have. I mean that, I mean, there are people that are creating similar libraries out there for some of this stuff, but it's always feels, i don't know, not not quite not quite there. So from an AI point of view, depending if you're just calling a guys, of course, fine, you can do that from anything, but if you're then trying to do some stuff yourself using it, then it doesn't quite feel like the right choice.

But maybe that's changing. It's only superficial knowledge that I really have of that, but I can't even 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 it just couldn't we're going to do like do it with prawn or something, where whereas you know, we we were using Java libraries that

actually did proper PDF rendering. But you know, there were there were other ways we could have tackled that but we chose the the different tech path as opposed to finding a ruby a ruby way to do that. But I'm sure there are lots of other exams force. But you know, I think where Rails still seem to shine is when it's much more of a well people people come crud apps that they like, kind of it's kind of a bit demeaning. It's like the agent is a

crud app. Yeah, I guess it's like, you know, it takes 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 cred app. You could say the same with you know, base camp as well app. Then what isn't notions of crud app? Isn't it? I

don't know? So that's that's who knows, So like, hang on, that's everything at some level, isn't it top maybe chat, GPT or something, But we're not we're not building that.

completely rails as well. The way I see, if there's something that you can't really do and Ruby or in Rails, it's usually something with quite a small footprinting, you could just extract that into its own service and build it using something else. So like like the PDF thing you said, so, yeah, you can't do that in Ruby, build that one tiny thing using something else and then just call it.

there and they're doing something cool stuff. There is obviously the conferences and the guide's looking a lot better now, But for me, it's like the outreach and how how can the Rails Foundation just get people an earlier stage in their career, I guess, and even boot camps and the rest of the rest of it to start using rails because boot camps did do rails back in the day, and now now they have tended to move from what I understand, it's more of a kind 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 like having to do like react sounds overwhelming to me, whereas at least with Ruby it's like kind of his I'll beat template and it's just basically HML. That feels a bit 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 showing. But I think that's going to be an important part of Rail's future successes, that is to get in at the ground again and they make people realize 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 so hopefully. I'm hopeful that this is this is already happening and we'll get better as well as people. Because there was a talk, wasn't there.

It was it Irena from Evil Martians and she did a talk about startups on rails or something. I didn't see the talk, but I think I've seen the slides, and you know, she talks about some really interesting companies and companies that were built in other tech that are moving back to like a rails. We were all micro services and now we're going to come back to a railed monolist 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.

And she was a boot camp graduate. She graduated from the Wagon quite recently, and they had a little bit of rare 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 customer element and JavaScript, and it was like, whoa, this is so easy. And it's like, yeah, I just wish bootcounts of beads that kind of stuff a bit more.

That's that's what they're there for. And if and if all the jobs reacts, then it's their duty to then go and teach people what's going to get them most likely to get them the jobs so they can have their you know, placement stats nice and high. So it's it's a tricky one. You need the jobs that otherwise a boot camps might say, well, this will be no jobs in that, so why would we bother teaching it? And then you're on a bit of a downward spiral. So yeah, tricky.

uploaded content. But the particular apps that I was building involved customers uploading photos and dragging potentially hundreds small hundreds of photographs into a drop you know, drop zone thing and uploading the wall and then viewing these things in the app. So you can view you know, three four hundred photos in the gallery of course with like infinite scrolls on. But this is quite a lot of requests on the app when your images, you know, are in

active storage. And you know, with my typefisted ways, I did you know that that's quite a lot of traffic in my app just on one page. It's a lot a lot of requests you know that I'm having to serve them. These images should really be on a cd N. Why are they even you know, the request should go directly to the cd and I don't want these requests hitting my app and that you know. So that's where that was where I started thinking, well, how do I

solve this? How hard can it be? And well, it's not that hard, but it's it's quite convoluted like so, you know. But there were two there were kind of there were two related problems, which is slightly tangential. One one being Rail's assets, you know, the CSS and the

JavaScript and whatnot. The other being the active storage images and solving those getting those onto a cd M. Two differ different problems that the assets approached well, and I was using cloud Front because I was on a w S and all the images are on in an S three bucket, so I thought, well, cloud Front's the obvious thing here that that must be pretty straightforward. But and

I presume it's similar for other CDNs. I was just using cloud Front and had these three credits anyway, so you know, it might as well and configuring that and this wasn't really documented in 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 cloud front and the BOOKHT 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 texts. Some were just active storage you know, has one attached, so just a file attached to multiple files attached to a model. The other being in action text you know, images that are inside an action text blocker, so indirectly active storaged

on my model. And trying to solve that was kind of an interesting one as well, because you have to set up particular routing, direct routes to do this and involved environment variables and different you know, and understanding how to actually configure this cloud from the d N as well, which I have to say is is part mystery, Like I forgurt 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 I wasn't that interested enough to actually go and understand exactly why. But I did document in this article like here's what I did, partly 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 took me a while to figure it out because not that information, not that much information was out there, bits and pieces on the Rails forums and various blogs. But so I

thought I'd try and encapsulate it. And it does seem to have worked because I have had a few people get in touch things. Thank you, Thank you for writing that, because I was banging my headgates a bit more trying to figure out how to make it work. So another thing I suppose that maybe the Rails could make a little bit easier, although it's quite complicated, all of this direct loads. If you look at the code in Rails for how how that works, it's quite it's quite hardcore

in my opinion. So that's that's the sort of top that's that's where it came from and how I approached.

time for this. The crazy thing is O course out of time. I just choose not to. But yeah, I think that could that could help because then you're expressing in code exactly what you're doing on this on the cloud front and on the S three boocket. In the case of active storage. But on the rails side, I mean there's not that much to do. I mean, you know, once you're certainly with well with with the assets, there's virtually nothing to do. Just have to set the asset hopes.

All the configuration is in in AS, where whereas with the active storage you have to create this direct route and then with that action text you have to then go and find the blog partial, you know, and go and change the route in the blog partial and things like that. But once than that, it's kind of straightforward. But it's yeah, fiddly, But I think that it's mainly fiddly because of the AS and if you if you

could automate all that stuff yourself. But I suppose a good test would be to try on another CDN, which I have not done. You know, would it work on Digital Lotion or or some other you know, people have the other image media image specific CDNs than they especially on the on the larger side of if your app is you know, a big commercial app, you might not use Cloud from the tour. You might go for one

of these proper image CDMs. How I have no idea whether that would be easier or more difficult, but ssumably from a Rails point of view kind of the same. You just have to get this route point to the right thing. So it's you know, it's it's more of an speak class problem, I would I would say than than Rails.

like that that's a big improvement. Hasn't had any issues that I'm aware of, you know, I mean clouds from pretty straightforward. At some level it works really well. Obviously you have to be what has been a ws for that, but I guess it helps if you're all in there. It would be interesting to know that, you know, if you're I don't know. It depends on what the thing is. This is another thing, isn't it like where where do people deploy their rails app? What's to go to thing?

Because again nothing's perfect, but camal looks great to me. But then it's like, and I've got a database, what do I do? You know, It's like, you know, do I have to pay crunchy data now? And well if I do that, then what if my you know, my app is on Hetzner, But well do I now have to build? When do I run that in a Docker container? Do I? And that isn't that for me? That is uncovered? Whereas actually that's the most that's the most important thing.

I don't really care about my web servers. It's my database that I care about. And you know, Heroka was good, but then they're kind of they're really tight fisted with the resources, which I don't like. But you know, so I don't know. That's another whole conversation, I guess, and that maybe for another time. But the definitive kind of

I think commands 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, is it the app one, the docker base one that they have is really a good idea, but in practice hasn't in my opinion, hasn't been that. It's not a great It's slow, but conceptually it's great because you can get managed databases there. I can just kind of deploy my being by a Docker so 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 a WUS because I had a loser credits and Hatchbox because it's just literally I don't even think about it. I just click a button and it works, which I think is great, and it sports Chris Oliver's brilliant Hatchbox. So happy to hand him money, you know, So that kind of interesting book camar If Hatchbox had Docker, then it would That's it is kind of like it's almost

game over. At that point I think.

But maybe not? Maybe render? Yeah looks pretty cool. Cool.

really fun. I use it for meetings to 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 lms and audio.

cards go on to 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, 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.

it anyway, it's awesome. So you know, it's part physical health, part mental toughness, part other stuff.

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 I've passed me by a bit, but I kind of really like it, so I should probably be on Mastered on should not. I don't mean that kind of passed me by, but big up Sky, go and check that out. I think 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 after the weekend, probably so it might be too late for people at the Edinburgh Festival. But I saw this show the other day which called Sawdust Symphony, which was one of the most incredible things. I've seen some crazy stuff at Edinburgh Fringe, but this was on

another level. It was the way they pitch it is carpentry meats circus and it's like three German guys for an hour on the stage doing things with wood and the whole stage show that including lathes and glue. It was. Honestly, it sounds ridiculous, but it's absolutely incredible. So I you could probably see some videos of it online saw Dust Symphony. I honestly I've never seen anything like it in all my years, and that I have a lot of years under my belt these days, so that would be my.