Olivier Lacan joins the panel again. He currently works for Pluralsight. Today they are talking about the spectrum of creating a Rails app, or any app, from the birth of the idea to the death of the project. They stress the importance of planning for updates. Olivier talks about his experience in maintaining Code School, which has now been incorporated into Pluralsight. David also shares his experience with the life and death of a project. They talk about technical debt and the trouble that it can create, and the importance of making your Rails application maintainable. 

Olivier talks about his experience when Code School was acquired by Pluralsight. The panel discusses the inevitability of the end of an application and different ways of managing company integration. They talk about ways to plan for shutting down a project. One of the best ways to make integration easier is to clean up your code and always be considering what data needs to be kept and what can be truncated. They discuss some of the issues around storing customer data and respecting individual privacy. 

The panel talks more about sunsetting, or the ending of an app. People often think that shutting down an app doesn’t have any impact, but it is important to give customers time to adjust to change, as Olivier found out with Code School. Dave talks about different reactions that one could have when change happens. The panel talks about some of the emotional implications of having to destroy something that you’ve worked hard on for a long time. Ultimately, your project isn’t where you should put your self-worth, because projects will come to an end. When things do end, it’s important to look back at where you’ve come from and the impact that you’ve had on people. 

Hey, everybody, and welcome to another episode of the Ruby Rogues podcast. This week on our panel, we have Andrew Mason. Good morning. Nate Hopkins. Hello.

Hello. Dave Camira. Hi, everyone. I'm Charles Max Wood from dev chat dot TV. And this week, we have a special guest, and that's Olivier Lacan.

Hello? Now do you wanna just, remind people who you are? We haven't had John for a while. That's true. So I am a French person.

I originally come from Paris, France. I moved to the US when I was, I don't know, in my twenties, to learn more about how to make websites and eventually ended up at Code School where I made websites. And, and then, basically, I've been running and maintaining Code School for years until it was acquired by Pluralsight where I work now doing interactive, education stuff, for people who like to learn web things. Nice. And, we had some discussion before the the call, but, yeah, Pluralsight's a a local company, at least to me, in Utah.

And it it was interesting when it got acquired, yeah, just to see where they would go with it. And it sounds like, just from talking to you there's a little bit of setup, and then you can dive us into this, is that, the kind of sunsetted code school itself. It sounds like they're still doing the content, but they're not using the platform anymore. Right. Do you wanna just, give us a rundown of our topic here?

It's the life and death of the Rails app. Yep. So, essentially, it's it's kinda talking about the the the whole spectrum of when you create a Rails app or any app, really, when you get excited about a technology, say, you're playing with Elixir or any other technology like that and you you start building it, the the excite the initial excitement and all the kinda, like, oh, dependency shelf, like, picking all the things and the candy jars and everything. And then when it starts actually getting customers and when starts getting traction and scaling issues and people scaling issues and eventually, either you're successful or not success successful, if you happen to be successful, either you stay independent or you get acquired. And when you get acquired, there's a lot of things you think are gonna be simpler, and, of course, they're not.

And either you stick around as kinda like a part of the thing that acquired you as an amp, you integrate, which is a whole a whole technical, you know, minefield. Or you just become completely ingested in a new thing, which is eventually what happened to us. I think it took 2 years. So there's there's just so many people things and technical things that can be discussed. But most mostly, it's just like this idea that we we always plan for the wrong things.

We're always, like, expecting, like, the web scale is gonna be the problem or, that, you know, anything that's not actually the real problem, which is usually people problem and, just like the churn and the technical debt and things like that, and then also the the end of it. Like, you just never plan for that. And for user privacy, for instance, there's a lot of problems, especially recently with GDPR, where when you close an app or you close a company, you have this treasured chest of privacy data that, you're supposed to do things with, now. And it used to be much simpler. Just, like, sell it to someone if you're not moral.

If you're moral, you try to safeguard it and put it somewhere safe. But if you get hacked, what happens? You know? A lot of a lot of data breaches happen like that because people put stuff away and forgot to lock it nicely. So, yeah, lots of stuff like that.

Interesting. A few other ways that I've seen this play out too are I mean, like, Twitter when they switched over to Scala, moved a lot of stuff off of rails, you know, for for different performance and scalability issues. And so that was kind of a rewrite. I've seen companies kind of peel pieces off because it's cheaper to run it in the cloud in different ways. You know, so there are a lot of different things that people are concerned with and I think also just to your point, when we get started with the Ruby on Rails app, I think a lot of times we don't think ahead just to the fact that eventually the current version of Rails is gonna become obsolete.

Right? And so sooner than later. Right. And so all of a sudden, you know, we've we've gotta update it one way or the other. And so I've I've talked to a bunch of companies where they didn't plan for, oh, we've gotta upgrade to rails 4.

And then all of a sudden, they're they've got a rails 3 app, they've gotta upgrade to rails 5. And so they've gotta upgrade and then upgrade again and then update all the gems. And so, yeah, this planning thing turns out to be a nightmare in some ways, but at the same time, I wonder is there is there really a good way to plan ahead for the things that are going to die off in your app or for your app to die off? It's tricky. I don't know if anybody has an opinion, but it's for for us, it was really tricky to plan ahead because every time we predicted as programmers, we're so bad at predicting everything.

We make estimates are completely lies and we know it. We try to make them better lies, but not, like, truth. It's super hard. So I think that for like, you gave an example of, like, upgrading dependencies. Let let me tell you how code school, the course runner app that had interactive, like, courses released every month worked.

Every month, we would make a new Rails app. That was the course. We would skin it, have our front end team design HTML, CSS, JavaScript, everything for that app. If there was improvements to the way that we were handling for like server side front end, front end stuff, we would make those improvements in the app at least at first. And then we would release a whole new app that was independent, talk to the, you know, main web server, like, domain code school dot com server with OAuth and APIs and asynchronous messaging and stuff like that.

Which means within a few months of being operating as a subscription based company, we had 20 or so rails apps with different versions. Some of them were still happy about that beta versions of rails that we're running completely different, like, security like, you know, patch versions or or even minor versions of of Ruby and Rails. So it's just, like, those are the kinds of things that you can't necessarily plan for a lot of other things. But the kind of decisions where moving fast and breaking things kind of mindsets, quickly quickly, you can see if you're you look around the the field and kinda take a breather for a second, you can see, oh, crap. This is not gonna work.

Like, within a few months, reassessing is kinda like this thing of, like yeah. The the speed of iteration quickly becomes where where basically, to me, it's like putting everything on a credit card. That's exactly how I picture it. Like, doing this kind of stuff is like, oh, you have a 17 or 18% interest rate and it's cool because you have this $20,000 credit limit, but that's gonna run out real quick. So, yeah, I don't know.

Planning is hard. GitHub kinda has a similar story where they forked rails and kind of had a custom flavor of it for several years and then finally have just got back onto the main line of of rails release, which is cool because now they can contribute back to the framework. Right? And that's actually Eileen, Eileen, you should tell and, Anne Patterson working on that a bunch. And they they gave a talk or she gave a talk at railsconf or RubyConf or I think it was crossconf.

Crossconf. Right? And that talk tells you everything. Right? It's it's just 3 sporadically with, you know, patchy involvement from a bunch of different people.

It's essentially a 3 year effort to or even more sometime just to get back to you're not that special. Right? Yep. And you can contribute back. And I think that's the situation that we find a lot of ourselves in.

It's you know, we read a blog article or we see something new and cool, and we're like, hey. I could use that in my application. And so now you have your standard, you know, very close to the rails core application. Now you're diverging a bit, whether it's adding in a gym or a client side framework or some other kind of infrastructure or architecture like microservices or Lambda functions. These are branching out or in your case, creating a separate app for each instance or product that you're doing.

And it it's going to complicate everything. Maybe not today. Maybe today you saved a few hours, but you're gonna end up costing yourself many, many more hours in the long run. And I think that's where technical debt can eventually cause an application to die if you're not maintaining it, if you diverge so much that now the application's almost unmaintainable because it's such a mess. Now those original people who implemented those ideas are gone.

Now you have a new group of people coming in, and they have, like, very little idea of its architecture. Where if you stick to the Rails core on something, then you're gonna be able to bring in any rails developer no matter who it is. And then they're gonna be able to look at the application, look at your gem file, look at your routes, look at, you know, some of the other things that you have going on, and they're gonna be able to get to production or, you know, start coding on it really quickly. And so I've made this mistake many times where I thought that, oh, I have this very special use case. And so I tried doing something, and it always comes back to bite me.

So recently, in the past year, I've been on this real kick where it's a question more or less, is your Rails application maintainable? And I think that if you can confidently say yes, then you're gonna be able to easily just bump the Rails version, do a bundle update on your application, run your tests, go to Rails diff, and then see the differences between the configuration files from your current rails application version and the new one. And then everything is just going to work. Updating rails should not be a hard process. We make it hard through the decisions that we've made over time.

Yeah. And it's also like the when you're in the the initial startup phase, it's very tricky because you're any longer than 15 minute problem solve feels like you're spending so much money that you don't have. And that's the infancy stage, which is very, like, you think, it's it's like you're a predator and you're trying to find something to eat because you're gonna die of starvation. It it seems very dire. So you make really, really bad I mean, it's the it there's a a similar problem with the poverty in general.

It's just like when you're impoverished or you're hungry, your brain doesn't have the the the same capacity to make, like, long longer term, safer, stable decisions. It's not because you're stupid. It's because it's you're in a bad setup in context. We had the same thing with people. Like, you just mentioned people coming in.

We had people coming out. Because startups, by very nature, just you people leave all the time because they, usually people who start things are not great at finishing them. It's gonna sound like a slight dig, but that's just a natural thing. A lot of people were like, oh, super excited and I have tons of energy at the beginning. They don't really like the the slog of maintaining things.

And as you said, if they customize everything, if they fork a bunch of gems, if they do all that stuff, then it's a nightmare. It but it seems like it makes sense during the time. And there's moments during the the Ruby and Rails development cycles where or even any gems cycle, you're like, oh god. This is not moving. Like, there's not it's not they're not doing what I want.

So I want them to upgrade. I want them to deprecate this other thing. I don't want them to use jQuery anymore. And you're like, ah, just for fork it because literally, fork it. I don't wanna deal with this.

And that's the moment that it's hard. Like, what you just said is very wise. But during these phases, these kinda, like, desert crossings or, like, the slow slumps in development of rails or Ruby or anything, you're like, screw it. I'll just fork it. Yeah.

Everybody that starts a project and and experiences that that pain in making some of those rash decisions should be forced to stay at a company long enough to deal with it. Oh, hi. I wish. And, you know History right in Elixir. Right, Nate?

Yep. You know, I know I've said this a few times, but I think my experience in rails projects specifically is rather unique because I'm going to hit my 10 year anniversary with the same job next month. And so I've had to live through all of the horrible decisions that I've made. And then looking back at those decisions, I'm like, wow, I cannot believe this idiot implemented something this way. Like, who the hell would decide to store images in the database?

Why did you think that was a good idea? And, you know, at the time, it was because, like, well, we have multiple web servers, so they need to be able to all hit the same images. And then, you know, like, well, why don't you just use something like s 3 or some cloud storage? Like, well, that's gonna be so many hoops I have to jump through because my bosses are going to, you know, require a vendor relationship and this kind of thing. So I'm like, the image is only 10 kilobytes each.

That's not a big deal. Just store them in the database. Well, 7 years later, that database table is over 30 gigabytes, and it just has a user ID and a image. There's nothing much in there, but it just got really utilized. So now it's like, crap.

What do we do? Now we had to convert all these base 60 fours back into a JPEG or a PNG, and then upload that to s 3 and then create some tieback into the Rails app. So it's a mess. But at the time, it was a decision because I was too lazy to go to management and request access to this resource to do it properly. So It made sense at the time.

Right? Even if you, like, slap on yourself, like, back in the back in time and you you travel, it's just like, oh, that makes sense back in time. This is why, like, commits are a big deal to me. And and and the the reason why I think anybody with long tenure values commits so heavily is that whenever someone leaves and you at least you have a commit, you can be like, okay. Well, I hate you, but at least I understand why you did this.

And, usually, it's you, which means tenure is humbling because quickly, like, within a year, you'll see commits. You're like, wow. Why is it like that? And it's you in that thing you just described because you're like, I'm stuck. This is my wall.

I have to deal with this thing, and I'm doing the best with the tools that I have. Yep. But it's just one of those examples where I diverge from the best practices route. And it worked at the time, and it was great. And it was because it was a business need or at least I justified it as a business need.

And then many years down the road, it's like, okay, it's just gonna be easier to rewrite this application or it's gonna be easier to do, you know, something else than to have to continue to maintain this thing because it was not maintainable. It didn't fit into this little paradigm of, you know, being able to just run bundle update, run your tests, and then do rails diff to see the changes. Now I've overcomplicated its architecture through poor decision. So I'd like to fold this kind of technical story back into the narrative that Oliver started with with code school being acquired. What and and it sounds like you maybe had some of these architectural, some of this arch architectural complexity, baked into CodeSchool.

What was the team dynamic like? So at the time of the acquisition, we had the my favorite team I've ever had. Like, it was the best structure of a team I think I've ever had. At the time, we had a team non computer scientists. And then the 2 women, one of them was a PhD candidate in, physics, who had dropped out for because it was driving her crazy that she couldn't get results.

Like, she wanted feedback, which sounds like a programmer problem. And then, the other Katie Delphin, who's now at GitHub actually, is just like this magic, like, context monster who just, like, absorbed context. She's a great team lead, basically. She had the the the computer science knowledge and everything, but more more importantly, she was very good at, like, 5 steps ahead thinking. Like, you we're gonna do this.

We're gonna do that. And so we had managed to build a system that was despite the fact that, yeah, we had limitations because of technical debt and the things Dave talked about where we at the time, vaguely remembering, but we had, like, roughly 3 to 5000000 users, not constantly, and then subscribers. I I vaguely remember those numbers, but I think we're in, like, 20,000, like, paid subscribers or something like that. So it wasn't gigantic, but it you know, there's a lot of things to do and often not enough time to do them. So we had to, like, cut and prioritize, and someone had to roll into marketing development occasionally.

A bunch of people are doing billing work. A bunch of people are doing iteration work. And then someone like me had to be doing technical debt stuff. So Ruby upgrades, long running rails upgrades, long running everything. Before, both Gymnasium and does which doesn't exist anymore, but has been rolled into GitLab and, Dependabot existed, which makes it way easier to deal with these things because as I don't know if it was Dave that mentioned that.

It was just, like, constantly de upgrading was, a thing that I was somehow to think that a human was doing this, it just sounds like such a waste of time. All these PRs that are open by Dependabot to update your dependencies are just, like, magical. So much so, yeah, that was the dynamic at the time. You gotta cut yourself some slack. I mean, with a team of 4 with 20,000 paying subscribers, moving like, managing the entire business, it's it's easy to see why some poor decisions might get made.

Right? Yes. Absolutely. Also, this is the kicker that I didn't mention is that, originally, Codeschool built its own billing system. It wasn't Codeschool's in any lab, so I blame them.

But they're they're nice people. They just plan to reuse it with customers, and they never did, I think. And so we had to maintain and move off of that to a semi like, Stripe has Stripe subscription now where it manages the the whole life cycle stuff, but it didn't do that before. So we had to still build that like everyone else and migrate everything. And I think that was the year we got acquired was the year we did that.

So we did all that work and then we acquired. And, of course, the people who acquired us were like, oh, we have this other subscription vendor. Yep. But I'm curious, kind of the the specifics to the acquisition in terms of what the intent was, what you thought was gonna happen versus what actually happened. I think I'm speaking for founders and and and leadership in in that sense.

I think for every SaaS software service company or even content educational company, there's always that fear that there's always the driving fear, which is, you don't have enough content. People stick around to drive up the lifetime value of a customer. So I think our LTV was around. I I vaguely remember, so this is probably wrong. But I think $80.80.

So it's, like, it's really hard to deal with those facts. When you see them, they're terrifying. This is the the data you gather makes you you fear of death is not just vague. It's like you have numbers for each of those things. You know that if in a month, more people cancel than the previous month and that trend changes in any significant way, you know that in 6 months, payroll is gonna black out.

Like, it's it you know, there there's it's really and then for people who love what they do and have a team that's fairly, like, well adjusted and there's not too much drama and it's it's it's fairly, you know, a healthy job, it's terrifying to see people that you consider even, like, good friends or acquaintances that you like to see them in the bull's eye of that reality. So I think that when the market started getting bigger and bigger and people getting acquired left and right and things like that, you'd kinda see, like, small producers like Peepcode and other people were acquired by by Pluralsight. Others were acquired by other companies like that. You could see that consolidation happening in in that, like, tech learning sphere. You're thinking I think the the thinking becomes, like, well, either we're gonna get bought out by someone or they're gonna drown us out by producing more content, pouring more money in it.

We were kind of in a high quality, compelling interactive content sphere, which few people competed in, but they had more marketing. They had more everything. They were louder. So we could get drowned out, I think was the fear. And I think the acquisition came after talking to several suitors more as a okay.

Well, we kinda fit in because they don't do that. Right? They don't do interactive stuff. Pluralsight is very much like video training. At least for many years, it's it's it's acquired and and rolled into its service multiple kinda like training mentoring services and things like that that are more tailor, made stuff and enterprise specific stuff.

But at the time, it was similar to the other offerings out there. And it was also kind of restricted to a subset of the technology space, which is Microsoft focused. And we were doing Ruby, Node, you know, a bunch of other exciting hot technologies, and front end stuff and and things like that. So I think they saw us as kinda like a differentiating factor, and for a while, they used us as a, you know, like a a premium offering. They you enterprise companies would would get that on top, a little cherry on top of code school.

And, originally, there's no plans. And this is the thing where a lot of people think like, oh, they said it would stay around, but it didn't. Most companies they had acquired, it's hard to integrate, so they'd rather have it as a separate service. Like, at least for whoever's manager or leadership at the time, they're like, oh god. No.

We don't wanna do that. So hard to do migrations. I I spent 6 months of my life doing a a customer migration with, like, Stripe and stuff like that. It was a it was horrible. Even if it's complicated to have 2 stacks or something like that, which is tricky, they'd rather keep it around and see what happens.

The problem is everything shifts when you get acquired. All of the that's the thing I try to talk about in the in the talk is that the things that you were scared of are not there anymore, and then you're scared of different things. So instead of running out of money, which was the driving fear, you start fearing, oh, we don't know this leadership. And if the leadership changes, the the agreements we've made with the previous leadership, there's no guarantee. And, also, like, what like, holding ourselves accountable when you're a startup and you're starved for, you know, sustainability, you make decisions that are more short term and you're and when you're suddenly allowed to make more longer term decisions, you get kinda cocky.

Like, you start doing things like, oh, we're gonna merge our engineering teams or we're gonna because I don't know. Let's try that. And we're gonna produce twice the amount of courses, even though we're about, you know, kinda like deep content and compelling content, we took a long time with every topic. We took, like, a month to make every course. We spent lots of money making very, very, like, compact and dense and, like, you know, something that can kick kick you, kick start you very, very quickly.

Not long, you know, 10 hour courses that you have to watch through. So we started kinda trying things, and many of those things didn't work, and I kinda lost momentum. And then it started making more sense for us to just be integrated into the ecosystem more to you know, through the years. And this is what happens to a lot of acquisitions where you lose the momentum because all of the parameters change. Even if you even if you said nothing will change, we have assurances.

Leaderships loves what we do. And there I think when we were acquired, that's the last thing I'll say, I think there were a handful, like dozens of developer at Pluralsight. And we had our engineering team was like at least twice or 3 times the size of their engineering team because they produced video content stuff. So they had they had no complicated, you know, evaluation of code stuff to deal with. And also they were like heavily focused on enterprise stuff.

So they did a lot more stuff there. Sorry. That was long. Yeah. So that actually kinda gets into, like, some of our our conversation before, podcast started, which is how do you plan for this stuff?

Because you had mentioned that that, oftentimes, we don't think about what it means to shut down a a product, even if it's just an internal app. Right? But a lot of this stuff, yeah, it's like you said, you can't foresee it. So how do you plan for it? To me, the the the great thing to do is to think about the things you don't need right now.

A lot of us, a lot of developers, programmers, and and web developers, we're kinda hoarders. Like, we like to have all the logs. We like to have, just in case we're gonna have this extra thing. Some of us are not like that, but thankfully, yeah, there's a few different people. But, the perfect example that I that I use in the in the talk that I gave was device.

Very useful tool. Gets you started super fast. You have user authentication, registration, confirmation. If you use it, you should use it. When you get acquired and you have not confirmed any of the emails you have in your database, that sucks.

But there's a a module in Devise that I for a very long time was included by default called Trackable. What Trackable does is log the IP address of the person who signs in with that user account, the last IP address, the current IP address, when they signed in, when the last time they signed in was, and then often people tack on what was the g, geo IP resolution of that? What was the country associated with the IP that this this person came from? That is I mean, for for still to this day, I think it's not considered PII, personally identifiable information by US government or the US entities, when it comes to that, but in Europe it is. So your IP is a piece of private information because you can determine a lot of things based on someone's IP, their email address, and everything.

You can you can take that metadata and make a a very interesting story of where they were, when, why, and all that stuff. And so when I gave the talk, I think it was in April 2018. Yeah. Devise had a, little no mention of GDPR, which is the European, privacy regulation stuff that came into, effect literally the day, code score shut down, which kinda tells you a little bit. And I found out just doing research before this, this, this call that device 4.5.0 was released on August 15, 2018 and removed trackable as a default module, which is great because unless you have a very, very good reason to have the IP address of the person who signed in for your service because you're doing I don't know.

You're you're having, like, massive fraud sign ups or stuff like that or people are hammering, like, DDoS ing your service. You should not be holding this data. And this is one of those things where, which is you can do a review right now of the things you're using. I have a quick other example. One of our, founders saw the Obama campaign did this really smart thing where, and people were signing for donations and they were failing to sign up or they were failing to sign in, there was patterns to how they failed to sign in.

So they they would save any failed sign in attempt, form submissions, or failed, registration attempt form submissions. I might be misremembering. And they would later just run some data against that and figure out, okay, what are the patterns of people who failed to sign in or failed to sign up? And then they would just analyze that data and then, oh, okay. We'll put some JavaScript in there and say, like, no.

You meant Gmail, not g meow. And that way you get a proper sign up because the email actually is the correct email and you know there's a there's a few different things that allow you to do that. We did that and we forgot about it because the person who set it up for just left the company. And so I found a database table that had oh, I don't even know. A 150,000,000 rows of sign in attempts with some PII.

Some of it, that I didn't wanna have. And it was a quick conversation with my team lead, Thomas Meeks. Something I remember saying, like, do you know about this? Why do we do this? Have we ever used it?

Nope. Nope. Nope. Can I get rid of it? Truncate by.

Cool. Awesome. I don't have to deal with it. I'm not responsible for it. Essentially, it's just it's just like, it's not not my job.

It's more like I do not wanna be liable for this stuff. And I think if if more people who build apps thought of liability as a vector of concern, they'd be they'd be a little bit more thrifty with the stuff that they gather. Yeah. The default, module and devices, I mean, you just slap gems in and who knows sometimes what they're doing. Right?

Yep. Exactly. Yep. And then there's also sometimes where, you know, if you need to store the personal information, there are some justifications for it, especially if you're taking in payments from people where I've been in a situation on Drift and Ruby where someone has disputed a charge. And that's not cheap, you know, especially if I'm only charging $15 a month.

The charge that Stripe charges me is $15 plus that fee that gets returned. So, I mean, that's almost a 2 times hit. And if I'm able to provide that, okay, this is the IP address that this person used on the credit card to sign up at. And then here, I have records where they have downloaded this video, this video, and this video with the same IP address. Now I have a more legitimate case to defend myself on that chargeback.

But it it's something that you have to be careful on because, you know, what what is the statute of limitations for a chargeback? You know, if a 30 day window passes, then that data that's 31 days old, do I need to keep it? No. Yes. Or can I truncate it?

And so I put in a psychic cron job that will basically go through and it'll remove all that historical data that I don't no longer need. There you go. That's exactly the kind of stuff that we rarely think we have time to do this when we're building a business. And then really, it's not that much work to clean up after ourselves. It's actually far easier to do it iteratively, like you're you're saying in a cron job, than at the very end when you realize, oh, crap.

I have all this data. And when a user cancels, for instance, for us, before the migration, we told people, hey. We're gonna migrate. You're gonna get a Pluralsight account unless you don't want one. If you wanna just wipe your data, just send us a send us a little request in this thing and you will we will delete everything.

That you have to be able to guarantee that. And GDPR enforcement can come after you and say, prove to us that you've deleted all that data. Which and you can take it out of the database, but still have logs. Backups. Backups and and your log files and backups of the logs.

Yeah. It's a nightmare. That's why I think having a very good reason, like Dave mentioned, is great. It's it's a it's better to have the problem first and then and then put it into place rather than assume, oh, what if we get that problem? It's kinda like turning on all the features.

So think a little harder before you just throw in soft delete to your application. Oh, god. This is this is, very relevant to my life. Yeah. And, you know, I think, Nate, paranoia, which is a really cool gem for doing a soft delete, that's really useful in certain situations where someone performed something very destructive that they didn't mean to.

You know, there's, you know, no matter how many times you give someone the opportunity to warn them, like, hey, what you're doing is very destructive. Once it's done, the data's gone. There's always a case where someone clicked through all those yeses and check boxes and type in their password to confirm. And then, like, oops, I didn't mean to do that, or I didn't know what it was going to do. Then it's like, you want to service the customer, but then you also want to service your customer's privacies on the other hand.

So it's a tricky situation that you get yourself into. So in a lot of situations where I will have a feature like that, there's a warning that or a disclaimer that, okay, we are able to retrieve the data, most of it. Certain data aspects of it is completely lost. And in this specific case, it would be all of the metadata about the user's PII information or, their PII. So any kinda last signed in, sign in counts, IP addresses, all that data would just get scrubbed from the database, but the user accounts, you could get back.

Otherwise, after 30 days, anything that has a deleted at that's over 30 days old gets removed or truncated out. I was mentioning this brief briefly, but, I I use an alternative to the paranoia gem called discard by, I think, John Hawthorne. Yeah. Also works at GitHub. And it's slightly different.

It doesn't hook into as many, callback cycles. I think it just, like, it sets that that table, and it's basically use scopes for everything you need to select if you wanna select. And it avoids the kinda, like, the the trap of having associations and and, dependent destroy stuff kinda become soft deleted automatically. It's nice to consider both. I think the soft deletion sounds super easy, and it's always never easy.

It's always like there's always a little tiny little thing that you didn't think about. And, also, for instance, like, loading, I think we had a problem like that in the in the app that we work on right now where, yeah, the, composite indexes or indices that we were using were not quite optimized for, the deleted at column because we thought we had far more deleted at things and removing that index actually sped things up, like, think crazy things like that. Anyway To Dave's point, it's actually kinda funny and and a sad state or commentary on our on our industry and some of our solutions in the sense that we're we're holding on to a lot of this PII, information kind of not necessarily trying to be malicious about it. It's just there in logs and in database backups. But when we do accidentally really destroy some records, it proves incredibly difficult to to get them back even though we have all the backups.

And this actually talks to a a a a mention, I think, that I I remember hearing this so much in the 2012 to 2014 era, which was era, which was we're not doctors. So it's fine. If we take down the website, you know, we're not you know, we're just teaching people things. It's not like we're, like, giving them benefits or, you know, we're not a financial institution like Square, for instance. And that's a great cop out.

It's a great way to not be responsible and adult about, like we do affect people. If someone, like, took out some time to learn something or they give us their financial data or their PII or something like that, it it is a responsibility. It's it's a big deal. And even if we don't call ourselves necessarily engineers as in licensed trade tradespeople engineers, it's a good aspiration to be a little bit more like engineers and doctors than, than just like dilettante. Like, oh, we just make webs we're just webmasters.

We just do do fun things on the side. Yeah. But it takes a convincing argument from, like, a senior team to get the business to move in that direction when you're struggling for survival. Right? Especially in that startup mode, when you're you're really fighting with with competitors and you don't know if you're gonna make payroll next month.

It is in it is very hard. And and sometimes I I think it's good to have those fights though. That's another thing. And back to the constraints in a way is not having enough money is good in a in a company. Not having enough time is good.

It's a forcing function. You need to be forced to make those arguments. You need to be forced to to have these these disagreements with your team where you say, I think we should do this, and the other person says, I think we should do that, that this other thing, and this is why. And that way, it it fosters a little bit more, especially when you have a team that's not just the monoculture of a bunch of friends that hired each other after college. Because otherwise, yeah, everyone's gonna agree.

It's likely that everyone's gonna agree. When you start getting different people with different backgrounds and everything, left field, like, here's why you don't take this data. It's great for stalkers. That's that's a point of view that rarely is seen from white males, for instance. Like, Goala check ins and, and Foursquare check ins or things like that where you if you don't think about it from the kinda like, the bad perspective, kinda like the, the attacker or a security researcher perspective, it you do stupid things.

Speaking of stupid things, there's, I think someone mentioned sunset at the beginning. Sunsetting. So that's more like jumping to the end. But the, the the the total lack of emotional honesty behind the word sunset to me is a thing that I rail about a lot, which is we are ending, killing, removing, destroying this thing. Right?

We're not sunsetting it. There's no, like no one's running on the beach in slow motion with, like, beautiful, like, pastel colors and everything. No. This thing that you loved And for us, like, a perfect example for code school is, apparently, a ton of schools in Puerto Rico were using code school for, education stuff. They were using either free courses because we had a ton of free content, and then a ton of boot camps were using our free content as kinda like inverted classroom things where people would go home, do a code school course, a free one, and then they they'd talk about it.

And we, like, kinda it's not really statue statute of limitations, but we when we told people we're gonna fold code school and turn it off, they were kinda like, what? I mean, I need this. I I depend on this. Like, I I am a teacher and I'm teaching these kids with this thing. And being kind of wishy washy about like what we're doing is kind of like a doctor saying like on the, on the bedside and being like, it's not looking good.

What do you mean? Like how much time do I have to find another place to do the thing that I do? And I just say there's so much of that in this industry, sadly. And I think that it's fine to say, Hey, I moved on. Like there's tons of startup founders that are bored within 6 months or 3 years, and they wanna move on to something else.

And how about we start saying that? Like, I think that's fine emotionally to say I had a ton of fun doing this thing. I mean, it wasn't necessarily my case with Code School, but there's tons of things like open source projects, for instance, where peep maintainers are like, there's they hate they hate the thing that they built. They don't wanna deal with it anymore. They're trying to find maintainers, and and they don't say in public the thing that they said, you know, on conference hallways, which is like, I just it stresses me out so much every time I get an issue or something like that.

And I'm just sunsetting involvement. Walking away in the sunset. I think as you mentioned, Olivier, it's just life, you know. People die, applications die. You know?

It's not a matter of if it's gonna happen, it's when is it going to happen. And that's not necessarily a bad thing. I think how you approach it, you know, to sunset or kill it off, and how you react to it is where the real difference is going to come into play. You know, for the foreseeable future, I plan to keep doing Drift to Ruby as long as I can, but there's going to be a time where time just no longer permits. It either did not generate enough revenue where I could do it full time, and then my kids are growing.

You know, I have a 2 year old, 4 year old, and 6 year old. So as they get older, their time is going to be a lot more in demand. So there is eventually going to be a end of life. I don't know if that is 3 years from now or 10 years from now, but I think it is something that I will have to start thinking about. It's like, okay.

Once it's done, what am I gonna do with all this data? Not only the users, which I would absolutely respect everyone's privacy, but all the video content that I've created. Now I'm gonna be hitting 200 episodes this year. And for me, I mean, that's been years years of my life that poured into it, and I would hate to see it just kinda die out. But, I mean, that's gonna be the reality of it.

Either the content's gonna be stale and old if I'm not maintaining it anymore or, you know, people would have moved on to something else, but it's a real consideration to take. It's a heartbreaker when when you've, when you've worked so hard to make content. And you you know that some of it's out of date, but it's it can still be a little bit useful, especially when it's free. One of the hardest things for me with the with the shutdown was, was try Ruby. So try Ruby was one of my babies, and it was like, there's that and try git.

So I I I wrote try git with a bunch of people from from Code School and and GitHub in 2012. And it was this thing that just, like, was infrastructure. It was like, bunch of people, which is like, get started. Like, see if you hate it or if you're terrified of it. There's a great way to show you that it's not bad.

It's not it's bad, but it's not that bad. And try reviews, likewise, like, it's just we we didn't spend that much time maintaining it, but it worked. It was useful. And now I'm glad there are alternatives, but at the time, it wasn't quite ready. And, likewise, I don't think there's there might be a a try git alternative.

But, for Ruby, thankfully, there's an open source version, the front end, like, open source version that's now available on the try, on the rubylang, dot org website. You can get to it. But seeing this resource, like this kind of like thing that, you know, people depend on disappear or just that you enjoyed writing and you're, you're proud of is, is not that emotionally just sucks. It's just very like, ugh. And yeah.

But it's okay. Sometimes things don't get going. So I've been through, you know, almost celebrating my 10 year tenure. But that 10 years, I've been through 2 company acquisitions. So my company got sold and then it got sold again.

So and I've stuck around with it for almost 10 years through the whole thing. And, you know, there has been some of that loss and application that had spent 4 years working on. As soon as the new company acquired it, they said day 1, all development on new features is going to stop and sales is going to stop on this. It's not a direction we want to go down. And, you know, how I internalize that and my reaction to it is really going to determine the route I go as a developer.

You know, I could just rage quit the company and go somewhere else where I'm appreciated, or I could look back and say, where do I put my value? Where do I put my worth? Is it in the thing that I created, or was it the experience that I got over the many years learning from my bad decisions, learning how to do something new? And if I can take that away from it, then you reduce your emotional attachment to the actual product because I'm a better person because of that product. Yeah.

No. Yeah. It's it's it's tricky also because of the kinds of people that tend to work on these early stage or just, like, young products. But basically, yeah, older older people in the industry tend to have families and kids and, you know, things like that. And when I say older, I don't mean like older than 20, which is a lot of people.

And I think that helps make your focus less. Oh my god. This gem that I built or this, you know, application is the treasure of my life and my sole contribution to the world. When you have kids or you you have a family, it's easier to move on from that stuff. And I think it's it's also good to have more people like that in the industry that are just, like that have kids already that that that's work in apps and create companies as parents, not as single dudes in a bedroom or in a garage, who have no responsibilities other than that and therefore derive every kind of validation from it.

I will say I have never lived through the death of a Rails app because I've been like, I'm so young of a developer. But I had a mentor. And one thing that he taught me that I still find valuable to this day is that you're gonna work really, really hard on something, and one day you might have to completely destroy it. And he taught me this, like, in the worst, like, what I thought to be the worst way possible. Like, it hurt at the time, but I'm really glad he did this because over time, it's really helped.

I worked a really long time on this feature. It was very, very, very early in my career, and it was not done well at all. But I had worked really hard on it, and the fact that I had gotten it to work, I was very proud of it. And I took it to him for code review, and he called me up. He's like, look.

He's like, this isn't really this isn't, like, a good way to do this. And he's like that's when he gave me the little spiel that you really need to learn that sometimes it's okay it's okay to delete the entire thing. He's like, so right now, we're gonna delete this entire thing and start over. It's so hard, though. I mean, I I I still have that problem even though I'm literally that person.

I have destroyed the thing that I worked on creating for years for, like, 6, 7 years. So still now, like, I'm still that person who I see people at conferences delete code for kicks, like, as a demo, and I'm like, but no. Wait. Archive it. Put it somewhere in Stash.

What if you need it later? Just git stash. And And I see you, oh, no. No. No.

We don't. We just git git stash pop or whatever command you use to delete a stash, which I don't know. And I'm in awe of the kind of distance. Right? Like, as you said, like, the the maturity of being like, it's okay.

My brain did this. My brain can do this again. Valuing your knowledge that you acquired. It actually kinda reminds me of a a college art class I took where, early on in the course, we had to produce a 100 pieces of original art in a week. And we brought them and turned them in, and the instructor then proceeded to rip them all apart in front of the class and said that destruction is an act of creation.

Oh, wow. That's a hardcore version of Andrew's lesson. It was very much a hardcore version. I didn't know my dad taught art because that very much seems like something that my dad has done. When I was young and when I was going off to college, I was writing these cover letters to send off to colleges saying, you know, here, this is who I am and stuff.

And he would look at it, and then he would just tear it up and say, go do it again. No feedback. No pointers. Just tear it up. Or if I was working on some kind of other project or, you know, something that I was getting his opinion on, he just tear it up and said, do it again.

So either you will learn or you will eventually learn that your projects isn't where you should put your self worth. You should put worth into them. You should care about them. But that's not where your self worth should get derived from. And even if it's the best thing you've done so far, which it definitely applies to me, you might never do something quite exactly that special, like, in the same way, with the same people and the same that's the hard thing to do with with any kind of project creatively.

It's like, oh, wait. There's tons of things I didn't like, but this was so great. But you'll do other things. And then because you've already done that one thing, you'll infuse a lot of these other things. And this is the joy that I've taken.

This is the people joy that I've taken away from the the the end of Code School was I've nurtured a a few people and few people have nurtured me. And we're all, like, kinda, like, seeding each other and pieces of the the spirit of Code School and things like Pluralsight, like GitHub, actually, like, other places where so Joel Taylor, who's on my team, works at TaskRabbit right now. Katie Delphin's at GitHub. Thomas Meeks is doing independent game development now. So it's like there's just tons of awesome things happening with all those people, and it makes me happy, and they're just all around.

And they always have this moment where they say, oh, you know, back in the day when we did it like that at code school, this sucked, but this was awesome. And this is an awesome thing that we did. Often it's about people stuff and more and more of the code stuff disappears. There's a few little trickery things that you're like, oh, then we had an we we figured out a way that was nice to do x or y, but it's rarely the code that's like, oh, that was so great. I wish we had saved it.

Now one of my earliest memories, speaking of code school, was Rails for zombies with Greg Pollock. That was one of my first introductions to Rails, you know, after doing Ruby for a while, and then, now I just wanna give him a little shout out. Really enjoyed it. Yep. And that's actually how.

That's my second Rails tutorial, and I did that Rails for Zombies beta in Orlando at the Orlando Ruby users group. And that's how I think that was six months or a few months into me learning Rails when I was still kinda like a a fun front end focus web designer type person and still in school. So I did that that little beta before they actually released Rails for Zombies, I I think in the fall of 2010. And then in early 2011, they launched their codesculpt subscription service, Airman. At the end of 2011, beginning of 2012, I started at at codesculpt.

So I I literally learned Rails on Rails for Zombies and then worked on Rails for Zombies. So That's awesome. Bunch of us did that too. Adam Renzel, who's also at GitHub now, also learned. I badgered him to try Ruby and and Rails while he was an instructor at Fulsale University where I where I went to school.

And he was within a few months, he was, like, good enough. Like, he made a gem and everything, and he started working there. And now he's just, like, doing super cool stuff. And it's just so satisfying to know that people who just knew nothing I remember listening to podcasts like this very podcast when I was in school and not understanding anything about MVC ORMs, you know, web development. And saying to myself, I will probably never understand this because I think the one episode I've I've listened to of some Ruby on Rails podcast talking about controllers, and we're thinking like, this word makes notes.

I don't understand what a controller does and why it's called a controller. It's not controlling. It's a router. It's routing things. You know, it it it as a as an English major at the time, that that's the only qualification I had.

It used to drive me crazy. And I really, really thought, I'm just gonna learn a little bit about the whatever this is, but I'm never gonna be good at it. And then it's just makes so it's so weird to see your name and people at conferences coming like, oh, I learned Rails from you or I learned RSpec from you. Like, what? I can definitely sympathize with that because in college, I listened to this podcast all the time and learned so much, but also knew almost nothing from it.

I was like, I don't know what these words mean. They're using all these terms and yada. And now looking back, I know what those words mean. Yep. And now I'm here.

So, you know, it's just natural progression, I think. I think it's it's a useful tool also to do that, especially when you have loss or things disappear or things end, like a Rails app, is to I do this thing called, time machine. It's a time machine something. It's like, ego time machine. So you take a time machine not with you, your person, but just take your ego and how your your sense of self worth back 6 months, back a year, 5 years, 10 years, and realize this thing you thought impossible, now you do it, like, on on a daily basis and it's not even a big deal.

And it doesn't even faze you. But it's good to do that because because I think, David, you're talking about the the sense of self and how much, or worse and how much you derive from the work you're currently doing. Like, what how much worth you derive from that? How much worth you put in it? I think it it really helps to go back regularly as a kinda like a a self care exercise to make sure that you you acknowledge and and appreciate how much you've learned and how far you've gone despite things starting and ending here and there, like school ending or a job ending or an app ending.

Absolutely. I was thinking about, I've heard DHH talk about Rails itself and say and and he's acknowledged, what if this is the best thing I'm ever gonna do? Yep. I mean, so I guess in a way, it's somewhat of a counterpoint. Right?

Pausing and saying that that might be the best I've got. And if you can recognize that and maybe, I mean, I think there's been a significant amount of luck as well and just good fortune and good timing and things like that with that have all contributed to rail success. But but that also kind of contributes to this idea of, I don't know. Maybe that's the thing we should stick stick with. Right?

In term from from his perspective. So the kind of similar to DHL, like, I I thought those thoughts of, you know, that this is the best thing I'll ever do. And and then it ended. And DHH is lucky because it didn't end for him, and he is very much in control of where it goes for base camp and for rails. So it's good for him, and I think it's it's nice that he's able to have perspective on it.

And people have helped him in the community have perspective on it because, of course, he gets tons of feedback from people in the community saying Rails changed my life. Right? And people have told me the same thing about CodeScout. They're like, you changed my life. I'm like, it's not me directly, but it's us.

And I think it's okay for it to keep going. It's okay for it to end. And I honestly think, like, it's hard to see where where you are. It's back to the planning thing or seeing ahead. Like, you don't know if it's gonna be the best thing you do.

You it might feel that way. It definitely will feel that way if you're doing if you create something like rails. Yeah. I've had people tell me some of the same things about the podcast, that the podcast changed people's lives. And it's it's interesting because in in some sense, I kinda see where they're coming from.

And then the other sense it's like, yeah, but we just kinda gave you the tools. You went and did all the work. Right? And so it's it's yeah. Where where does it all come in?

Where does that all come down? And yeah. So I I think some credit is deserved, but on the other hand, I mean, people went and did the work. They they figured it out. So I don't know.

Yeah. I think to one of the original points was taking a lot of, satisfaction and fulfillment from the relationships that have been created and established along the way. That's where the real value is. Oh, yeah. That's absolutely true.

Alright. Well, we're we're kinda getting toward the end of our time, and and I think we've kind of minded this topic for now. So, let's go ahead and do some picks. Nate, do you wanna start us off with picks? Sure.

So I just recently listened to just yesterday the, keynote from RailsConf from DHH again, and it's it's really just fantastic. It's a it's a terrific exploration of what open source is, what it means to contribute to it. It's also kind of a love letter to Ruby. It was, just very well thought out and, highly recommend it if you have not seen or heard that keynote yet. Nice.

I'm trying to get DHH on so we can talk about it. So we'll see what we can do there. Right. So I have 2 picks for us? Yeah.

I have 2 picks. The first pick is I coughed up the money, after seeing the like 6 or $7,000 Apple display. Cause I've been in the market for 1, but I was holding off until I saw what Apple is going to do with their 6 k. I'm like screw that. I'm not gonna buy that.

So instead I got the 5 k screens from LG with the Thunderbolt 3 connector, and they are amazing. The quality on them and stuff are really nice. And, you know, after seeing a $6,000 price tag, a $1,000 didn't seem as bad. And since I'm on my computer all freaking day and night, I figured that having a quality display was, you know, you know, justifiable. And I had another pick.

I forget what it was. So I'll just go with that one. Wasn't there a bunch of blowback after WWDC when they announced the 6 k monitors and how much they were gonna cost? Well, it's the stand that actually made people go crazy. Oh, what oh, it's the stand.

Yeah. People people almost booed if you watched the keynote. It's very audible, like, what? When they announced a $1,000 stand for a 5 4 or $5,000 monitor? Because Yeah.

I think the best argument I've seen on the Internet was someone said, like, just announce the whole thing. Say it's $6,000 People are gonna be like, yeah, sure. It's Apple. But if you split the 2, it just sounds insane. And, it it makes sense.

I you know, almost would have been better if they'd said it costs that much and people remove the stand in the cart and see, wait, it's $1,000 cheaper. I think they would have as a negation, it would have been or subtraction would have been way better for people to discover. Heck, I'll just get a 2 by 4 and some nails. I mean, it kinda kinda looks like that. Alright, Andrew.

What are your picks? I usually pick technical picks, but today I have a more out there pick. I'm choosing wild sardines, from Wild Planet. And I don't know if you guys like sardines at all, but I thought I hated them. But then I actually tried them and I actually really like them.

And these are a little bit more expensive than your 99¢ can but they're a lot better after having tried some of the lower quality ones and they're super healthy for you as well. My nutritionist actually recommended them. So yeah, that's my pick. Nice. I only eat sardines to gross my kids out.

So I'm gonna jump in with a few picks here. So, one is is I'm currently at Velocity, which is a conference put on by O'Reilly. It's for DevOps. They combined it with the software architecture. And so anyway, I've been, talking to a bunch of people.

I'm gonna go meet a bunch of other people today. This is mostly, revolving around adventures in DevOps which is a show we're starting soon so check that out. If you were a fan of the Foodfight Show which is a DevOps show that was put on by Nell from, Chef and Nathan who used to be a chef and is now at Google, then, you know, Nell is helping us pull this one together and get it rolling. So I'm excited about that. And she's been on the show before too so I'm gonna pick that.

I also wanna shout out about Pluralsight. They've got a ton of great courses there. So, if you wanna go check them out, you can. I have an affiliate link for them, but you don't have to use it. Just go check them out because they've got good stuff.

I have a lot of friends who are Pluralsight offers as well, so that that's definitely worth doing. Yeah. And then, 2 more picks really quickly just because I'm excited. My wife em or texted me in the middle of the podcast, and she's like, check your email for your Father's Day present. And, she signed me up for ButcherBox.

And ButcherBox is a box subscription where they send you meat, and I like meat. So, yeah. They, they ship it out every every month. You get a box full of meat. And, you feel like you had to because of the sardine pick to balance things out a little bit?

Sardines? I don't think of sardines as meat as much as I think of, like, steak and pork. And anyway meat too. Yeah. Is there a, jelly of the month club?

Probably. Sorry. The National Lampens joke there. It wouldn't shock me at all at this point if there's a jelly box. But yeah.

So, yeah, I'm excited about that too. So, I'm gonna pick that. And then when I came out here, I booked my hotel through Hotels dotcom. So if you're looking for a way to save some money on a hotel, that's a great way to go too. Olivier, what are your picks?

So I I'm gonna start with, a counterpoint because I have to. I'm a meat eater. I'm a carnivore. I'm a French person. Therefore, I eat, like, milk and all the things, dairy, everything.

But because I like my planet and, I'm I'm trying to be kinda conscious. I actually made, this is gonna be kinda like a half self self pick. There's 2 things I don't like is waste and, like, needless waste. And the other one is, like, if I can reduce my impact or I can help reduce my impact on on, like, just crap everywhere, I try to to not drink milk if I don't have to. So if I need to consume, like, a whole glass of milk, I'm actually drinking something called Oatly, which is stupidly good.

Oat milk or oat I don't know. Liquid, if you wanna be contentious. It just has exactly what none of the, substitutes to milk have, which is, like, a little bit of fatty, like, content in it in it to make it, like, substantial. And it works pretty well with coffee. There's a barista edition for people who like to to use whole milk with their coffee that's just thicker and it works better for that.

And actually, I'm a coffee nerd and when I stretch milk, I can make it look like wet paint and it's beautiful and it's delicious and it mixes in perfectly. But at least a little bit more like 2% milk in that in that regard. But it's super good and, fewer farting cows. So it helps to kind of reduce that a little bit. And I again, I love cheese.

I'm never gonna get rid of cheese, but I can reduce milk consumption a little bit because milk is, like, not really that. When you kind of try other things, you realize it's not that amazing. And then there's, there's something I haven't tried, but I kind of want to try. I love rib eye specifically. It's my favorite cut.

But when I eat burgers, I'm kind of curious, like, ground meat in general is is there's a lot of research to try and make alternative ground meat. And there's Impossible Burger and Beyond Meat. If you have one around you, just as a cure like, intellectual curiosity, try it out because I've discovered that I I don't like alternative fake meat stuff, but things that are good and that you use to to replace ingredients with not just that to pretend that they're meat, but to to be like, hey, this is also good. A lot of the the the impossible burger beyond meat, all that stuff is is pea based. So this is pea protein.

And pea has kinda like a dirt, kinda like similar irony taste as meat, red meat. It's not going to be a a substitute, but it might be good, like a legit good thing to eat. So that's one thing I wanted to mention. So in the in the wastefulness kinda like sustainability angle, I made a little website for Earth Day called horizonzerowaste.com. If you get the pun, you're cool.

If you don't, it's fine. And it's basically the stupidest little front end. It's just an HTML repo. It's actually markdown. I'm pretty sure if I remember correctly.

There's, at the bottom, you can see there's a a link to the GitHub, repo. And it's just a list of things you can do as alternatives to things that are wasteful. So for instance, bottled water is just straight up it makes no sense. Like, just there there's so many ways to drink water in metal bottles like this Corkcicle bottle that I have. It's an Orlando based company.

They make super good Zojirushi is a Japanese company that makes it really easy to drink from mugs that you don't have to unscrew and things like this. Carrying around a a water mug or a water jug or anything like that is just, like, makes a ton of sense. There's these machines in the airports everywhere where you can, like, get filtered water now these days, so it's just, like, everywhere. So that's one of the examples. There's plenty of things like that.

It's not just all about, straws. There's a lot more stuff that you can avoid doing. It's stupidly easy for most of them. So I encourage you to just, like, type in anything that you want to try to be less wasteful about in the whole type of keyword box at the top, anything plastic. You can see alternatives like metal.

Metal's cool. You can smelt it and, you can turn it into something else. Plastic, not so cool. A great example is dishwasher detergent. It comes into big jugs that are basically full of water.

Powder detergent works exactly the same because you turn it into water with your dishwasher, and it also means that people are not shipping boxes of water around the world. So it helps. Now I have more techy pics. I'm just gonna go go through them really quick. I'm a an amateur photographer, and for years, I try to fight, Apple Photos or, like, work with it.

And probably they're gonna improve it with the new, macOS version, but it's it's still not quite good enough for the kinds of insane amounts of photos that I take. I take, a lot of photos that end up being, like, 250,000 shots in 15 years or something like that. So it takes a lot of space. I want it synced across devices. Turns out Adobe was there a while ago.

They're they're still there, and Lightroom CC is one of those things where I'm not paid to say this, but as someone who's just a a software nitpicker and a photographer, they've kicked ass on Lightroom CC. It's efficient. It uses SQLite as a kinda like a, local storage database, but it's all kinda like, canonical in the cloud based, which means it's always synced extremely fast to a lot of devices. It has machine learning search, like I mentioned in the pre call, where you can find, like, photos of coffee mugs or photos of rugs when you're looking for a thing that you haven't categorized in a in a thing, and it works surprisingly well. It's fast.

The editing is seamless. You can do a lot of things with the keyboard. It's it's really impressive. And I think they have, like, cheap or free tier plans for 30 days or something like that where you can try it out. I I iPhone app, macOS app, and pretty much every platform.

Even the web app is great. What's your preferred camera? My camera is nuts. So this is not a recommendation because most sane people would not spend that much money on a camera. So I have a a Sony RX 1 r, 2, which is a full frame fixed lens camera that's a 35 millimeter lens, f 2.0, Zeiss lens on a basically, the same sensor as the, mirrorless a 7r2 by Sony, which is the the big fancy Sony DSLR, basically.

It's not DSLR, because there's no mirror, but it it's one of the best there. The the sensor is the big thing, big ticket items. It's just an incredible 50 megapixel sensor or 47 megapixel sensor. And it's a full frame camera, so you get all that, you know, soft focus stuff and and bokeh bokeh. And yeah.

So if you like photos and stuff like that, it's it's good stuff. Very cool. Alright. If people wanna find you online, Olivier, where do they go? So olivierlacan.com.

That's my email too. Hi at me. That's the same for Twitter. O l I oh, wow. I'm trying to spell my name and I'm just like you can find me.

If you put Olivier and Ruby in the in the Googles, you can probably find me. On GitHub, same thing. And I do a bunch of open source stuff. I keep a change log. And, Yeah.

That's me. Nice. Alright. Well, thanks for coming and talking to us. Thank you for having me.

Alright. Well, we're gonna wrap this one up, folks, and we will be back next week.