Transcript

XO Ruby San Diego 2025 - Optimize for developer speed by Claudio Baccigalupo

From Confreaks · Episode page · Watch on YouTube

· 40 min · 7,206 words · 57 timestamped sections

This is the full, timestamped transcript of "XO Ruby San Diego 2025 - Optimize for developer speed by Claudio Baccigalupo", an episode of Confreaks published January 8, 2026 (40 min, about 7,206 words). It mentions 9 people, works and ideas, including Rails, Playwright, Hotwire, Honeybadger, Turbo.

What is discussed, and when

  1. – 5:00: Claudia Bachigalupo
  2. – 25:00: Hotwire, Pico CSS
  3. – 30:00: Hotwire
  4. – 39:36: Twilio

Notable quotes from "XO Ruby San Diego 2025 - Optimize for developer speed by Claudio Baccigalupo"

  • Hello everybody. Welcome to Exo Ruby San Diego. My name is Claudia Bachigalupo and I have been coding with Ruby and Rails since 2006. And Rails is both the way in which I make a living and my passion. And I've had several jobs.
    about Claudia Bachigalupo · at
  • Because I found it when building this project. But I found a CSS framework. It's called Pico. It's Pico CSS. And you like it?
    about Pico CSS · at
  • Least you have to do something and so another you know feature another library that came with rails is hotwire and what hot wire does is it lets you know put your web app in a…
    about Hotwire · at
  • Expire this offer because if it don't respond, we want to send it to another one. Then it uses, Twilio to connect them and a lot of other stuff.
    about Twilio · at

Who and what is mentioned in this episode?

People

Companies & orgs

Products & tech

Concepts & topics

Full transcript with timestamps

Hello everybody. Welcome to Exo Ruby San Diego. My name is Claudia Bachigalupo and I have been coding with Ruby and Rails since 2006. And Rails is both the way in which I make a living and my passion. And I've had several jobs related to Rails in my career. And my career has grown over time. You know, I started as a developer, senior developer, principal until in 2018, I became an engineering manager. So until then, I was doing a lot of contribution to Rails. I was you know made a lot of contribution to the source code. I was running the LA Ruby and Rails meetup. I was speaking at conferences but then that stopped because being a manager means you have to do other things. You have to hire interview and all of that.

So I thought that was it. I thought that wasn't going to be the change in my career. But something happened basically exactly a year ago. Um I uh work at a startup where I was exactly an engineer manager and uh you know startups change in people and do what startups do. So at that point uh we had a team of 11 developers and then the next day it was just me. I was the only person left doing any coding or engineering and um also I was tasked with maintaining all the existing Rails apps and building new ones. So something clicked in me because you know for the recent years I hadn't really done a lot of Rails and you know I had read the blog post. I knew there were more versions coming but I hadn't literally had the time to do it and so you know I felt sad because I I liked my team and I felt lucky because I still had the job and also it was kind of like a challenge. Oh, I've always wanted to

play with Rails 718 and now it was my chance to do it. So, here I am a year later and I still work at the same company. I'm still the only developer engineer and over this time I've actually built uh five Rails apps from scratch. The latest one was actually shipped yesterday. So, if I have time at the end, I'm going to show it so you guys can join. But um what I'm going to show you today is the first one that I built because right when that happened, we still had a client who had a deadline and I had to deliver in two months. So today I'm going to show you a bit of that app and then I'm going to talk about the choices that I had to make to you know deliver and and I mean in time.

So um this uh is part of the app and what the customer does is they do uh pet grooming. So if you have a cat or a dog they do it mobile. So they come with a van to your place and they take care of it. So after landing on a you know marketing page that they have customers have to go through a flow where they you know this is exactly the flow and this is what I'm going to show you. So this is the flow uh you know you enter your your your details then the address where the van should come to service your your pet then you uh specify at least one cat or dog and then based on the breed you're going to see some services that are available. So you pick a few services at this point you schedule it.

So you pick an available date and time uh and then you see a confirmation page then you confirm and that's it you you've booked now. So maybe you don't work for you know mobile pack grooming but I feel that there might be some things in this app that relate to other Rails apps and um you know this was really kind of like what I did those were those two months and these are some of the methods that I used and I'm going to talk about and a lot of these methods didn't even exist you know five or 10 years ago they're new but it was really a pleasure to you know kind of like a relearn rails and uh really build something that for instance has a lot of interactivity without a single line of JavaScript has kind of like a mobile version you know all of that stuff. So it kind of gave me the joy again of of writing rails. So this is going to be our journey for the next 20 minutes. So let's start. Are you

ready? Cool. Okay. Guess how this whole thing h start. Can you guess how it started? what command rails new exactly that's exactly what I did no magic in that so I did rails new uh but throughout the whole process I had one mantra which is to code fast you know I had to match this deadline plus as you can imagine product specs changed every week you know to get there so I really had to focus on how can I make this this fast so I feel there are two ways to do that the first one is use tools that you know. So personally I am more expert in Postgress SQL than my SQL and they're kind of equivalent for this project. So I picked Postgress and that's what I did in the first commit you know because I was going to move faster with that.

Other times to go fast means to spend a little time today to save time in the long run and this is why I did the dash main option. So what that option does is instead of uh using a specific version of Rails like 7.1 or something like that, it uses the main branch of Rails on GitHub. So literally the latest commit, you know, not even the latest version. The reason why I did this is because in the past whenever I had a Rails project, I really hated those days where it's kind of like, okay, today I have to update from Rails 5.1 to Rails 52. I, you know, it's just not something that I like to do. It takes time. and so on. So if you point to the latest version, you don't have to care about that. You're always, you know, up to date.

Uh, another reason why it's good that you're literally using the latest version of Rails is that you are bound to find bugs. You know, nobody has used that version. So you might use it and find a bug. And the good thing is that if you find it, you can fix it and then you have it. And I know this sounds a little like a stretch, but that's actually what happened to me. I hadn't done any commit to rails since 2018 and because I was using the latest version I was finding some things that were not you know documented or something and I would fix them they would get merged and I would pull the latest version they were there so you know if you think how can I contribute to open source well definitely you know using main is is a good way because if you're using an older version maybe that bug has already been fixed Okay, so we're talking about Rails. Uh Rails is known for being MVC, you know, models, use controllers. So I'm going to

talk about these uh four parts of the app. And I'm going to start from models. Can you guess what is a model that I have in my app that I maybe every app has? User. I think everybody has a user model. So, uh I know it's like 9:00 am, but here's some Ruby code for you. So, this is kind of like how the user model uh looks. And I'm going to go through, you know, several parts just to give you some examples of how I code. So, the first thing that you might notice is that there are these comments. So, on top of each class or on top of each methods, I I do this comments and it looks like English. It's a syntax called yard which is not that different from English. And the reason why I use this is because in the past I've used this when creating Ruby gems. And what's nice is that then you can run the yard command and it automatically generates the documentation for all of your code.

So you don't have to write it somewhere else. It's in your code. And it's very helpful not only because I'm coding on five rail stops at the same time and I forget but also someday somebody else might have to manage this code and so it's already there. And uh one of the checks that I put in the code is that the code has to be 100% documented. So if I forget to add it when I push it says you know this method is missing and it doesn't take you know it's one of those other things. It takes really like one second today, but then I imagine we're we're gonna hire somebody else.

They don't have to ask, you know, they can just go there. Here's something else that I added which is pretty new in Rails. Whenever you have uh sensitive data, so for instance, for a user, you may have the email or their phone. It's a good idea not to store it in plain text in your database because if somebody accesses your database, they're going to have all the personal data. So there is a very simple way to do that in Rails, it's just this one commit, this one command called encrypt and you put it there and then what happens is that in the database all these fields are going to get encrypted.

So you don't see the actual email or phone. the only way to decrypt it is through the key with the Rails app and it's really just like one line of code. So what I mean here is even if you have to code fast don't you know uh still consider the security of your data. So you can use encrypts just like that with no parameters or you can use it with some parameters like I do for email. So let me explain you what that means. When you encrypt with active verical encryption the same text twice, you're going to get two different encryptions.

In generally this in general, this is okay. But if you want to find by specific field, you don't want to do that. It has to be deterministic. Otherwise, you know, find by email is not going to work. So that's when you use that deterministic option. And down case true is also a nice thing. That means emails are not case sensitive. So you're telling basically store them in the database down case because it doesn't really matter and you can just do it with that option. So down casing all emails it's called normalizing. That's how you normalize the data in your database. And there's actually another pretty new method in Rails which is called normalizes that you can use uh on its own. For instance, what I'm doing here is users as you saw before can enter their phone number. you know, they might type, you know, a dash, a space, or something like that. I don't really care in the database. I only want

to store the digits. So here, I'm normalizing whatever the user types, and I'm deleting everything that's not a digit. So then it's nice in the database. So as you can see, these methods are pretty easy to use and pretty powerful. So far so good. Okay. So something else that I personally really like is to have short files when I code. You know, I like my files to be short because I open them and I kind of can read them. And personally, I'd rather have, you know, 50 files that have 20 lines of code than two files that have a thousand lines of code. And sometimes when you write models, they become long. So there is a way to keep them short by extracting behaviors in in concerns. So concerns are uh you know like like mixins or uh modules where you group some features together.

So here is an example when we talk about a user apart from having a phone and an email a user had the feature to be recoverable that means you know when you forget your password and you get a link and you click on the link and then you're logged in. Okay there are some methods for that and they're grouped together in a concern. Searchable means you know you can find by email and there those are other features and so this is how you you know include them in the in the class so they don't uh pollute your your your class itself and I want to show you one of these concerns. This is the recoverable that I was talking about. Okay. So this recoverable what it does is you have this recovery token. Imagine you know when you get the email and says click here or type to login and then when you uh do that the application recognizes your token and the nice thing is that I didn't have to write this code like I

don't have to think about how long should this token be you know how can I make sure it's secure and all of that because rails now ships with this two methods signed ID and find sign that do all of that for you. So signed ID generates a token and you can even specify how long it lasts. In this case it's four hours. So if you click on that email you know after four hours and try it's going to say you know link expired try again and then find signed is you know the mirror the one that you give it the token and it finds your your user and all of this also works if the email is encrypted in the database. So once again pretty powerful and you see this is maybe like you know eight lines of code. So, you know, that's just something else that uh shipped uh with Rails in the recent years and you can all use.

Okay, so that's it uh for models. Uh let's uh let's talk about controllers. You know, I've shown I've shown the video of what the app does. So, you already have an idea of, you know, what a user can do. Can you know create an email, enter a pet and so on. And that's what the controllers do. And if you want to look at the controllers, I think the first file you want to look at is the config routes because it basically lists everything that the app can do. So this is the config routes of the app. So you know you you see all your pets, you can create your user, you can log out, you can enter the location where the van is going to come, you can enter your pets and and so on, right? So um something that if you've ever you know written routes in rails you know there are different ways to do it. You could use the get method host and so on. But what I'm doing here is just using basically the resource or resources

methods. This means that all the routes are restful like they're all resources. And uh I really like this because it's um one of the convention over configuration over Rails is that if you do this then anybody who opens a controller knows that they're going to find the rest actions new edit you know update and so on. Sometimes you might feel the urge to break from this. You know an example would be at the very end you see a confirmation. So you might think, oh, you know what, that's a booking get confirm or something like that. But you can think about that a little more. You can say, no, confirmation itself is is a resource.

It's kind of like an object and I'm showing the confirmation. So, you know, this is another suggestion that I have. If you keep your routes resourceful like this, it just uh, you know, saves time when you have to think about it because you know where everything is. and it also helps other developers. Um, okay. So, let's let's look at a controller. So, this is actually, you know, where at the very end of the flow where somebody confirms the booking and then, you know, you're confirmed. So, something I didn't mention before is that this whole app is actually backed by, you know, the company who does the back grooming. So think of it as kind of like you know Google flights or an app like that or ticket master when you confirm we actually have to ask the API is this time slot available and then if it is we we book it you know so two people cannot book at the same time and so this is what the user sees you know

the user sees this final form where they have to check the box then let's say that they check and they click on book service so what they see right away is this sort of kind of like loading page age because at this time we're you know sending the request to to the company hey I want to book this can you tell me if it's okay and then when the response comes back the user doesn't have to reload the page or anything it becomes like this your service has been booked so there is this dynamic you know interactive part in the browser where I'm clicking I'm just waiting and then it shows up and you might think that I have to write like a lot of JavaScript you know I have to maybe like open a websocket and you know listen for this response and then parse the response and all of that and it's true that in the past you would have to do all of this but another thing that uh is included in Rails 8 is Turbo 8. So with Turbo 8 it

gives you this all this behavior with literally two lines of code and no JavaScript. So this is this is how it works. So imagine we're on a booking page. This is a booking. Well, the show is just show the booking, right? But the booking maybe at the certain point is still pending. So, we're showing that loading bar. Then, as soon as the booking become confirmed, the page changes and says your service has been booked. To do all of this, as I said, you literally need two lines of code. First of all, in booking, you add a line of code called broadcast refreshes.

What this does is it it's telling the model itself, hey, whenever you change, broadcast your change to whoever is listening. So if somebody's listening for changes, you just broadcast it. In the back, it's using, you know, action cable and so on, but you don't even have to worry about that because it's all the convention. And then in the view, this specific view, you use turbo stream from the same model, which is the opposite. Say, hey, listen for anybody broadcasting changes to this object. And when you get it, refresh the page. And that's it. Like this is that behavior that you've seen that it spins, you know, and then it changes. It's just done by the these two methods. Once again, pretty powerful. I like coding in Ruby more than in JavaScript. So, I'm really happy I was able to do this.

How we doing? Cool. So, um, we come to test. Who likes test? Everybody loves test. You know, when you work at a project like this, you might think, do I even need test? Do I even have time to write tests? You know, are they going to help me? As I was saying before, the the project specs changed over time. So, it was actually important for me to have tests because somebody asked, can you change this? I kind of want to make sure that, you know, I'm not breaking anything else. But I also didn't want to spend too much time writing test. So I found my own compromise which is I use a system test and uh I only wrote one test which literally goes through the entire app simulating what the user does. So this is an example of system test. The user goes to the root so you know the homepage and then I'm just doing everything that the user does. So I see this text I fill in the first name with a name the you know last name and so on

and I continue. So I'm basically describing the whole flow of a user from start to end. And uh when I run this, the good thing is that a browser pops up on my laptop and I can see it. As a matter of fact, that video that you saw at the beginning, it wasn't me doing stuff manually. It was me recording the system test running on my computer. So I really like it because you get this visual confirmation. You can also send this video to, you know, your product manager say this is what the app does. That's everything that it does.

Plus you, you know, if you mess up your CSS, your HTML or something like that, you see it. You know, it's kind like, oh, this, you know, if you delete an image that's supposed to be there, it's like, oh, look, there's an image that's missing. So, it kind of saves you a little bit of that. And then you can see what it looks like on mobile and on that on laptop and so on. So, in my case, using system test uh was was pretty good. And not only I use them, but just like I did for documentation, I enforced that the entire codebase must be tested.

And I did that with a gem that it's not in rails. You have to import it. It's called simple cov. Simple cov when you run your test measures which lines of code are tested and you can add this simple cove minimum coverage 100%. So if there is a line of code that's not tested, it tells you. And sometimes what that means is that the feature is not used anymore because you know product has changed. So you're like oh I can't delete this file now because it's not used anymore. And uh you know to give you some context running the whole suite on my computer was taking uh 22 seconds you know on a CI can even be faster. And at the beginning I was using uh selenium which is kind of like the default. But recently I've changed to playrite which does the same thing as selenium but it's less flaky. You know sometimes selenium tells you something is there that it's not. But if you use playright it's it's

much more stable. So you don't even have those issues of something passes but then doesn't pass. Uh finally I want to talk about views. um you know you have to to build those pages like they they kind of have to look you know somehow usable and if you write no CSS at all or nothing at all if you just use the rails scaffold something like a form would look like you know the one to the left which is just just just the bare minimum you know and you want to add something on top so to go fast you probably want to use a framework you know bootstrap tailwind something like that and I've used them and I check them. But the problem that I have using them is that whenever you add it, especially Tailwind, then you have to go to your HTML and add a bunch of stuff. You know, you have to edit your HTML and add all the classes and stuff like that. So, I was thinking, can I just put a, you know, a framework and I

don't have to touch HTML at all. And I actually didn't know this existed because I found I found it when building this project. But I found a CSS framework. It's called Pico. It's Pico CSS. And you like it?

I love it. I love it, too. And the good thing about Pico, you even read it in their homepage. It says, "We're going to give you something and you don't have to touch the HTML, you know, it's it's it's minimal, you know, you don't get maybe all the features, but so the same form just applying PO looks like that, you know, and of course you can customize it, but to go fast, it's it's pretty powerful. So, you know, check it out. You know, it might work for your for your project." And uh the last thing I want to mention about the views is that sure you know we are web developers we do at least I am web developers but these days you have to do mobile as well like you know at least you have to do something and so another you know feature another library that came with rails uh is hotwire and what hot wire does is it lets you you know put your web app in a mobile frame and kind of like look good. So I also

gave it a try to see what it looked like. So let me show you how it works. So with Hotwire, if you don't do anything, what it does is I'm giving the example here of iOS. It basically takes your website and it puts it as a web view in your app. So the good thing is that it works. It's just, you know, a web view in your mobile app. The bad thing is that it doesn't really look native. like you know you have things like that button at the bottom like you you kind of get the feeling that you're on a web page right or even the header being you know in the nav bar twice so this is what I really like about hardwire that you start from a place that already works and then you make all these adjustments you know kind of like okay it works but it's not really nice now let me fix this and let me fix that so even if you don't have too much experience you can go step by step so I just want to show you an example

How do we remove the title that's there twice? And how do we change the button at the bottom? So, normally on iOS, it would be a link in the knob at the top right. Okay. So, you want a page like this where there's a next button and the the title is not there twice. There is a library called wire native bridge that helps you with that. So, you include it in your app and for instance, if you want to move that button, you know, to the top right as next, you just put some data attribute. So you'd say it's called you know how our native bridge. So the attributes are called bridge. So you say bridge title next bridge for ter form target submit and then you open this in you know in in iOS and the button goes there with the same functionality or if you want to remove the title from you know the H1 because it's already in the nav whenever you want to change your views so some things just look different

on native there is this helper called turbative app question mark. So in that case I'm just saying hey you know show the H1 unless we are a native app because in that case it's already in the nav. So this is just to say you can go step by step and you can try it out and uh since then there have been many more uh native Hawai native bridge components released. So you can do really like a lot step by step which I think is a better approach than just saying okay now go and learn swift from zero and go and learn cotling from zero. So I really like that too.

So um to conclude um I mean this is really like you know what I relearned is that I've done a lot of Rails in my life you know as a junior with the team managing and so on and now kind of like rediscovering from scratch I really think that it's the best oneperson framework. There are things I didn't talk about here. You know, deploying, you know, as an example, you know, you can use come out. Um, you know, there's a lot of things that you can really do by yourself, but, you know, these are some of my suggestions and I don't think they're hard. You know, that's then the other thing is that you can do it. You can do it step by step. You can start with the conventions of Rails and, you know, they're going to help you go there. And um, that's all I have. Thank you.

Any questions? I have one. Uh so you said that you're using Playright. Yes. Does that uh substitute in for selenium then?

Yes. So there is a Ruby jam called I think it's called playright capibara something. So you just remove selenium and you put that one in. So selenium um playright is less flaky because it's more strict meaning when you do your assert tax and so on. If you do something that playright doesn't understand the first time you replace it you're going to see some errors but then you fix those you basically to like write your assertions in the correct way and then it's much better and then you don't get flaky specs anymore.

First off, thank you Clauddio. It was a great presentation. Um, a couple questions. Um, it's pretty cool. You're using a system test, so you don't write any unit tests at all.

I don't write any unit tests at all because they, for me as a single developer, they don't have any value. Like I honestly don't care if a method in the user model does one or the other. I just want to make sure that the user the the user has the experience that I want. So because those system tests cover 100% of the code, those methods are already tested, you know, so I don't need to test them twice.

I think it's great first off. Um, we have so many different types of tests where I work and it's sort of like h you know, but and anyways, so the next question was um you talked about hotwire and how it can make it look so that it's a native app. I really like that um set of a web app. Um was there any specific syntax that you need to consider for say like Android or would that also work with Android?

No. So how how wire native bridge it works the same. So those methods that I described they are the same. Okay.

Now in terms of I didn't build there are functionalities like you know you want your phone to scan a QR code or to access your health data or things like that that are specific. So those might be different you know. So devices have different things that then require different code but the basic things and they're the same unless you once again wants to access your contacts you know things like that you know.

Cool. Thank you. Um was there anything that you tried and then like decided against using?

As I said the project changed over time. So there's code that I wrote and then we didn't need anymore. And uh my personal approach and if you go online my one of my latest co talk talk is called the art of deleting code is I always delete everything and uh everything that I don't need you know so if I try something and then you know products like we don't need that anymore I've had co-workers saying oh you know let's keep it there just in case you know especially at the startup that just in case never happens because next month you have another project so I can't remember something specific speific but definitely if I tried and then we changes like okay this is gone because anyway we use git and with get you can always go back to what you had and so that's kind of like what I do got a question about encrypt and normalize usages yeah um is like it's two two separate questions in in the case of encrypt do you know if there's a

toll on the on the performance of of of using encrypt basically because changes the nature of your indexes probably uh you need to encrypt to then compare at the database level. So I I've not used that at scale for example especially for not uh for for fields that are not encrypted. So that's the first part of my question. And then similarly to normalize does active record handle the normalization when you go into the quering or or or or you have to take care take care about that on your own.

Yes. So those two questions are kind of related. So if I want to encrypt the normalize fields that I don't need to index like first name is just something that I I don't index by first name. So that I I don't you know I don't really care too much but something like email you're right. And so the answer is yes. So if you have an encrypted uh field like email in my case you can still do user find by email user where email. And the nice thing is that sometimes you add encryption later on. So you have some records in your database that are not encrypted, you know, and some that are and it it takes care of both, you know.

So you you can add encryption without worrying about the existing ones because you can do where and it matches both of them.

Interesting. Okay. You talked about the operational side of this since you're a solo developer. Are you the only person on call all the time like how do you deal with things falling over and things like that?

Yeah, I am. And and that's why that's why you know those things like you know testing and so on. I like I'm going to give you an example like on on a single day I might be deploying to you know three different apps at the same time. Staging production deploy and all of that. So and I also have you know honey badger things that tell me when there are bugs. So I really want to minimize that because I would be the one you know seeing those and also I don't want to give you know bad experience to the user. So you know being the f only person it means that nobody is going to deploy on a Sunday without you knowing.

So at least you have that covered you know but at the same time yes and that's why you know I feel somebody you know recently asked me well if you're the only person do you still have code quality right because nobody's there to look you know but yes I do for myself you know because otherwise something like that would happen you know we we deploy and then it's like it broke right so right now um you know I'm just going to uh close showing you because the one that I showed you you might not have that. Oh, I don't have Oh, sorry. I don't have internet. But um the I'm going to show you like a if I have a second another app that uh we launched yesterday and you actually might like this one because um what this does is if you need a handyman anywhere in the USA then you can um use this application and it's a little more complicated. Let me show you what it does. Okay, I think I have internet.

Okay. So, if you if you need a handyman, you can go to start the houseaccount.com. It's a flow where you What happened?

Oh, sorry. Uh, there we go. Cool. So, if you need a handyman, you can go to start.acon.com. As a user, you're going to type, you know, what's your issue? this you know behind the scenes it's it it connects to open AAI to ask you the right questions it summarizes it then it fetches um uh third party providers uh from the internet once again with you know technology scraping and so on and it uh matches you based on a you know match of what you need with the skills to the provider to a provider it sends an SMS to the provider saying hey we have a customer for you do you like it or not meanwhile it starts a background job to expire this offer because if it don't respond, we want to send it to another one. Then it uses, you know, Twilio to connect them and a a lot of other stuff.

So all of this I built by myself and yes, I'm kind of like on call 24/7, but I'm here right now. I don't want to get a message that is broken, right? And so that's why I use all those kind of like uh you know, protections basically for myself, you know. But yeah, if there's something broken in honey badger, I'm going to get a a message. Start house. Oh, if you need a handyman, give it a try. We literally launched the yesterday. So

that's all. Yes. So I had like a follow-up question on the encryption stuff. Uh it is very cool and uh I think a good like default choice for sort of green field apps, but I worry for like much larger apps that need to stick around for 5 years, 10 years. Um, and I know just to be clear, like I think 37 Signals does encrypt a lot of their user data, but I still worry I'm was going to ask you like what would you do defensively to make sure you never lose your production uh encryption key for that data. So this question I think relates to your product team. I'm going to make you said what happens in five years. I'm going to give you an example of what happens tomorrow. Okay. So, you do all of this, all of this. You're like, you know, I care for the data to be encrypted. And then maybe somebody in your product is like, hey, I want to run a SQL query against the production database because I want to run a report. You know, they

can't do that. Like, you know, they're going to see the encrypted data, right? So, how do you deal with that? It's kind of like the same example. It's really something that you need to figure out with within your company, you know, like what what's the most important feature? Do you do you want the data encrypted like that? you know it there's a lot about data like another thing that I can do is um I um in incinerate the data that I don't need after a while and it's a similar thing you know some some company going to say no we want to keep all the data forever you know but for me for the customers and also so that the database doesn't grow forever I delete it but these are all discussions that you really need to have in your company you know like pick one you know if you can't have both right so it's just going to The technology lets you do it in a very easy way but then it's a discussion that

you have to have with product. Right. Uh last question and sorry. So do you keep these applications on main of rails forever? So anytime you're going to change you're going to pull a oneliner you're going to pull fresh main or do you eventually these down? Uh so at the beginning I had Rails on main and then I was very careful with the semantic versioning of like no I need this version of this gem this version this gem you know all of that you know what I did I don't have any versions anymore in my gem file at all they always speak to this one now you're going to think okay what if something breaks that's exactly why I have 100% system test because I do upgrade I do bundle update not every day you know every week every couple months whenever I see is dependabot or something, right?

I do bundle update. I push a branch to GitHub. It's going to tell me if something broke or it's going to tell me if there are warnings. So, if it's all green, I don't have to worry. Everything that the user was doing, the user can still do, you know, and that's kind of like my my approach. If I find something that doesn't work, the tests are going to fail. And that's when maybe I'm going to, you know, send a PR to Rails and say, "Hey, you know, this thing broke." This has been my approach. I know it feels a little like living on the edge, but I'd rather live on the edge than, you know, like, oh, this is version two.

What version is out now? Or whenever you have a security patch, it's sin. That's that's my personal approach.

Okay. How about I stay behind? Thank you.

Questions about this episode

What is discussed in "XO Ruby San Diego 2025 - Optimize for developer speed by Claudio Baccigalupo"?

In order: 0:00 Claudia Bachigalupo; 20:00 Hotwire, Pico CSS; 25:00 Hotwire; 35:00 Twilio.

What is mentioned in this Confreaks episode?

9 people, works and ideas are mentioned, including Rails, Playwright, Hotwire, Honeybadger, Turbo, Claudia Bachigalupo. Each one on this page links to its own page with every episode that mentions it.

How long is "XO Ruby San Diego 2025 - Optimize for developer speed by Claudio Baccigalupo"?

The episode runs 40 min; the transcript is about 7,206 words in 57 timestamped sections.

More from Confreaks

About this transcript: the episode's spoken words as captioned on YouTube, split into timestamped sections. Reclip.Me locates every person, work and idea in the text, keeps the time it is first named, and quotes the words around it verbatim. Last updated January 24, 2026.