Hey, everybody, and welcome to another episode of the Ruby Rogues podcast. This week, on our panel, we have Andrew Mason, Good morning, Nate Hawkins, Hello, Hello, Dave Kimira. Hi everyone. I'm Charles Maxwood from duv Chat dot TV. And this week we have a special guest, and that's Olivier Lacart. Hello. Now, do you want to 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've made websites and then basically I have been running and maintaining Quotes School for years until it was acquired by Plural Site, where I work now doing interactive education stuff for people who like to learn web things.
Nice and we had some discussion before the call, but yeah, Plural Sites a local company at least to me in Utah, and 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 as a little bit of setup and then you can dive us into this. Is that the kind of sunset of code school itself. It sounds like they're still doing the content, but they're not using the platform anymore. Do you want to just give us
a rundown of our topic here? It's the life and death of the rails app. Yeah, so essentially it's kind of talking about 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 an elixir or any other
technology like that, and you start building it. The excite, the initial excitement and all the kind of like oooh dependency shelf, like picking all the things in the candy jars and everything, and then when it starts actually getting customers, and when it starts getting traction and scaling issues and people scaling issues, and eventually either you're successful or you're not successful. If you happen to
be successful, well, either you stay independent or you get acquired. And where you get acquired, there's a lot of things you think are going to be simpler, and of course they're not. And either you stick around as kind of like a part of the thing that acquired you as an app, 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 two years. So 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 going to 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 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 GPR, where when you close an app or you've closed a company, you have this treasure 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 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 Skala, moved a lot of stuff off of Rails, you know, 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. 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 a 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 going to become ob right, and so sooner than later, right, and so all of a sudden, you know, we've we've got to 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 got to upgrade to Rails four, and then all of a sudden they've got a Rails three app. They've got to upgrade to Rails five, and so they've got to upgrade and then upgrade again and then update all the gems and so yeah, this
planning theme 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 had an opinion. For us, it was really tricky to plan ahead because every time we predicted, as programmers were so bad at predicting everything. We make estimates that are completely lies, and we know it, and we
try to make them better lies, but not like truth. That's super hard. So I think that for like you get an example of, like upgrading dependencies. 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 HTMLCSS, JavaScript, everything for that app. If there was improvements to the way that we were handling for like server side 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 ooth and APIs and synchronous messaging and stuff like that, which means that within
a few months of being operating as a subscription based company, we had twenty or so Rails apps with different versions. Some of them were still happy about that. Beta versions of Rails that were running completely different, like security version, like you know, patch versions, or even minor versions of a 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 look around the feel and kind of take a breather for a second, you can see, oh crap, this is not going to work, Like within a few months. Reassessing is kind of like this thing of like, yeah, the speed of iteration quickly becomes We're 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 seventeen or eighteen percent interest rate, and it's cool because you have this twenty thousand dollars credit limit, but that's going to run out real quick. So yeah,
I don't know. Planning is hard. Get Up kind of 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 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 Ann Patterson working on that a bunch and they gave a talk or she gave a talk at res coff for Ruby CLF or I think it right, and that talk
tells you everything. Right, it's just three sporadically with you know, patchy involvement from a bunch of different people. It's essentially a three year effort two or even more sometimes just to get back to you're not that special, right,
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 where 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 rail's 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 micro services or lend of functions.
You start branching out or in your case, creating a separate app for each instance or product that you're doing, and it's going to complicate everything. Maybe not today. Maybe today you said 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 is 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 sit to the rail's corel in something, then you're going to 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 gym file, look at your routes, look at you know, some of the other things that you have going on, and they're going to be able to get to production or you know,
start coutting 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 going to be able to easily just bump the Rails version to 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 all so like when you're in the initial startup phase, it's very tricky because you're any longer than fifteen 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 like you're predator and you're trying to find something to eat
because you're going to die of starvation. It seems very dire, so you make really really bad I mean, it's that there's 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 same capacity to make like long, longer terms, 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 the prime with people
like you just mentioned people coming in. We had people coming out because startups, by very nature just people leave all the time because they usually people who start things are not great at finishing them. It's kind of sound like a slight dig, but that's just a natural thing. A lot of people are like, ooh, super exciting and I have tons of energy at the beginning.
They don't really like 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. But it seems like it makes sense during the time. And there's moments during the Ruby and Rails development cycles where or you're in any gem cycle or you're like, oh god, this is not moving, like 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 jiquary anymore. And you're like, oh, I just fork it, because literally fork it. I don't want to 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 kind of like desert crossings are like the slow slumps in development of Rails or Ruby or
anything, You're like, h screw it, I'll just fork it. Yeah, everybody that starts a project and experiences that pain and making some of those rash decisions should be forced to stay at a company long enough to deal with
them. Oh hi, I wish, And you know, 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 tenure 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 as three or some cloud storage, Like, well, that's going to 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 ten kilobytes each, that's not a big deal. Just throw them in the database. Well, seven years later, that database table is over thirty gigabytes and it just has a user idea and to 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 sixty fours back into a jpegger AP and G and then upload that to S three and then create some tie back into the rails at 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 travel,
it's just like, oh, that makes sense back in time. This is why like, commits are a big deal to me, and the reason why I think anybody with long tenure values commits so heavily is that whenever someone leaves and 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 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. Yeah, but it's just one of those examples where I diverged from the best practices route and it worn't 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, be able to just run bundle update, run your tests, and then do rail stiff to see the changes. Now I over complicated its architecture through
poor decision. So I'd like to fold this kind of technical story back into the narrative that all of her started with with Code School of being acquired, and it sounds like you maybe had some of these architectural some of this architectural complexity baked into Code School. What was the team dynamical life. So at the time of the acquisition, we had my favorite team I've ever had, Like it was the best structure of a team I think I've ever had.
The time had its team non computer scientists, and then the two 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 kid, Delphin, who's not kid, have actually it's just like this magic like context monster,
who just like absorbed contest, is a great team lead. Basically she had had the computer science knowledge and everything, but more importantly, she was very good at like five steps ahead thinking like you, we're going to do this, We're going to do that, And so we had managed to build a system that was despite the fact that, yeah, we had limitations because I think that and the things Dave talked about where we at the time vaguely remembering
but we had like roughly three to five million users, not constantly, and then subscribers. I vaguely remember those numbers, but I think we're like twenty thousand, 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 innovation work. And then someone like me had to be doing technical dead stuff. So Ruby upgrades long running, Rails upgrades long running everything before both Gymnasium and which doesn't exist, Amurba has been rolled into get lab and depend about 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's just like constantly be 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 opened by DependaBot to update your dependencies are just like magical so much so, Yeah, that was the dynamic at the time. You got to cut yourself some slack. I mean, with a team of four with twenty thousand paying subscribers and 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 Quotes School built its own billing system. It wasn't quot schools Enny Lab, so I blame them, but they're they're nice people. They just planned 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 stripe has Stripe subscription now where it manages 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 got acquired, and of course the people who acquired us were like, oh, we have this other subscription vendor. Yeah, I'm curious kind of the specifics to the acquisition in terms of what the intent was, what you thought was going to happen, versus what actually
happened. I think I'm speaking for founders and leadership 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 LCV was around I vaguely remember, so there's probably wrong, but I think eighty dollars. So it's like it's really hard to deal with
those facts when you see them they're terrifying. This is the data you gather makes 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 six months, paar Roll's going to black out like it's
it, you know, 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 bullseye of that reality. So I think that when the markets started getting bigger and bigger, and people are getting acquired left and right and things like that, you kind of see like small producers like peep Coode and other people were acquired by Bipolar Site, others were acquired by other companies like that. You could see that consolidation happening in
that like tech learning sphere. You're thinking, I think the thinking becomes like, well, either we're going to get bought out by someone, or they're going to drown us out by producing more content pouring more money in it. We were kind of in the 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 okay, well we kind of fit in because they don't do that, right, they don't do interactive stuff plural siden is very much like video training, at least for many years, it's acquired and rolled into its service multiple
kind of like training mentoring services and things like that. There 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 things like that. So I think they saw us as kind of like a differentiating factor, and for a while they used us as a kind of like a premium offering enterprise companies would would get that on top and a little cherry on top with 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 stare around, but it didn't. Most companies, they get 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. I'm like, oh god, no, we don't want to do that. So hard to do migrations. I spent six months of my life doing a customer migration with like stripe and stuff like that. It was it was horrible. Even if it's complicated to have two 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 tried to talk about in and 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 agreements we've made with the previous leadership, there'seral guarantee and also like what
like holding ourselves accountable. When your 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 kind of 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,
kind of 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 uh like you know, something that can kick start you very very quickly, not long, you know, ten hour courses that you have to watch through. So we started kind of trying things and many of those things didn't work, and I kind of
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 say nothing will change. We have assurances, leaderships loves what we do, and there I think when
we were required, that's the last thing I'll say. I think there were a handful like dozens of developer at Plorocyite, and we had our engineering team was like at least twice or three times the size of their juring 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,
says Loan. Yeah. And so that actually kind of gets into like some of our conversation before podcasts started, which is how you plan for this stuff? Because you had mentioned that that oftentimes we don't think about what it means to shut down a product, even if it's just an internal app. Right, But a lot of the stuff, it's, like you said, you can't foresee it, so how do you plan for it? To me, 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 web developers or kind of hoarders, like we like to have all the logs, we like to have just in case we're going to have this extra thing. Some of us are not like that. But thankfully, Yeah, there's a few different people. But the perfect exempt that I use in the talk that I gave a boys 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 module in device that
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 GUIP resolution of that, what was the country associated with the
IP that this person came from. That is I mean, for still to this day, I think it's not considered PII personally identifiable information by the US government or the US entities. When it comes to that, but in Europe it is so your i P 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 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 twenty eighteen, yeah, device had a little no mention of GDPR, which is the European Privacy regulation stuff that came into effect literally the day quotes school shutdown, which kind of tells you a little bit. And I found out just doing research
before this call. That device four point five point zero was released on August fifteen, twenty eighteen, 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 having like massive fraud sign ups or stuff like that, or people are hammering like dedossing 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 the things you're using. I have a quick other example one
of our founders saw the Obama campaign did this really smart. When people were signed up 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 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 fail 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 gimial. 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 end things that allow you to do that. We did that, and we forgot about it because
the person who set it up just left the company. And so I found a database table that had oh, I don't even know, one hundred and fifty million rows of signing attempts with some PII, some of it that I didn't want to have. And it was a quick conversation with a team lead Thomas meeks. I think 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 want to be liable for this stuff. And I think if more people who build ups thought of liability as a vector of concern, they'd be be a little bit more thrifty with the stuff that they gather. Yeah, the default module and device is I mean, you just slapped gems in and who knows sometimes what they're doing, right, Yeah, exactly.
Yeah, 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 fifteen dollars a month. The charge that Strip charges me is fifteen dollars plus that fee that gets returned, So I mean that's almost a two times hit and if I'm able to provide that Okay, this is the IP address that this person use on the credit card to sign up at and then here I have records where they have downloaded this video, this video in this video with the say my p address. Now I have
a more legitimate case to defend myself on that charge back. But it's something that you have to be careful on because you know what is these setul limitations for a charge back? You know, if a thirty day window passes, then that data that's thirty one days old? Do I need to keep it? You know? Or can I truncate it? And so I put in a psychic crown 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 saying, in a crown 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
going to migrate. You're going to get a pluor side account unless you don't want one. If you want to just wipe your data to 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 your log files and backups of the logs. It's a nightmare.
That's why I think having a very good reason like Dave mentioned is great. 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 kind of turning on all the features. So I think a little harder before you just throw in soft delete to your application. God, this is a
very relevant to my life. Yeah, And you know, I think Nate paranoia, which is a really cool gym for doing a soft delete that's really useful in certain situations where someone performs 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 yes's and checkboxes 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, and then it's like you want to service the customer, but then you also want to service your customers 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 kind of last signed in signing counts, IP addresses, all that data would just get scrubbed from the database. But the user accounts you could get back otherwise after thirty days.
Anything that has a deleted at that's over thirty days old, gets removed or truncated out. I was mentioning this briefly, but I use an alternative to the paranoia gem called disc card by I think John Hawthorne. Yeah, it also works in GitHub and it's slightly different. It doesn't hook into as many callback cycles. I think it's just like it sets that that table and it's basically use scopes for everything you need to select if you want to select.
And it avoids the kind of the trap of having associations and dependent destroy stuff kind of become self 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 little that need, little thing that you didn't think about.
And also, for instance, like loading, I think we had a problem like that in the app that we work on right now, where yeah, the composite indexes or in disease 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 crazy things like that. Anyway, to Dave's point, it's actually kind of funny in a sad state or commentary on our on our industry and some of our solutions, in the sense that we're holding onto 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 get them back, even though we have all the backups. And this actually talks to a mention I think that I remember hearing this so much in the twenty twelve to twenty fourteen era, which was era which was we're not doctors, so it's fine if we take down the website, you know or 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 is a responsibility. It's a big deal. And even if we don't call ourselves necessarily engineers as in licensed trade trades people, engineers. It's a good aspiration to be a little bit more like engineers and doctors than just like diletant, like, oh, we
just make webs We're just web masters. We'll 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 going to make peril next month, it is. It is very hard, and sometimes I think it's good to
have those fights. Though. That's another thing that back to the constraints in a way, is not having enough money is good 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 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 this other thing, and this is why, and that way 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 going to agree.
It's likely that everyone's going to 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 go all the chickens and four square check ins or things like that, where you if you don't think about it from the kind of like the bad perspective, kind of like the the
attacker or security researcher perspective, it you do stupid things. Speaking of stupid things, there's a I think someone mentioned sunset at the beginning sun setting, so that's more like jumping to the end. But the total lack of emotional honesty behind the words sunset, to me is the 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 a beach in slow motion with like beautiful like pastel colors and everything. No, it's this thing that you loved and for us, like a perfect example for code school is apparently a ton of schools in Puerto Rico we're
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 kind of like inverted classroom things where people would go home do a Code School course, a free one, and then they'd talk about it, and we like, kind of it's not really statue statue a little limitations, but we when we told people were going to fold Code School and turn it off, they're kind of like, what I mean, I
need this, I depend on this, Like 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, but 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'm moved on. Like there's tons of startup founders that are bored within six months or three years, and they want to move on 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 maintainers are like, oh, they hate they hate the thing that they build, and I don't want to deal
with it anymore. They're trying to find maintainers and they don't say in public the thing that they say, you know, I'm conference hallways, which is like, I just it stresses me out so much every time I get an issue or something like that. I'm just sundsetting involvement. I'm walking away in the sunset. I think, as you mentioned, Olivia, it's just life. You know, people die, applications die, you know, it's not a matter of if it's going to happen, when is it going to happen,
And that's not necessarily a bad thing. I think how you approach it, no 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 drifting Ruby as long as I can, but there's going to be a time where time just no longer permits it. Either deny generate enough revenue where I could do it full time,
and then my kids are growing. You know, I have a two year old, four year old, and six year old, so as they get older, their time is going to be a lot more end. So there is eventually going to be end alive. I don't know if that is three years from now or ten 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 going to 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 two hundred episodes this year, and for me, I mean, that's been years and years of my life that poured into it, and I would hate to see it just kind of die out. But I mean that's going to be the reality of it. Either the content is going to 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 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 shutdown was was try Ruby. So try Ruby was one of my babies, and it was like, there's that and try get. So I wrote try get with a bunch of people from from code school and GitHub in twenty twelve,
and it was this thing that just like was infrastructure. Those like a bunch of people which like get started, like see if you hate it or if you're terrified of it, here's a great way to show you that it's not that 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 try get 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 ruby lang dot org website. You
can get to it. But seeing this resource like this kind of like thing that you know, people depend on, this appear we're just that you enjoyed writing and you know that you were proud of is is not that Emotionally, it just sucks. It's just very like ugh and yeah, met it's okay, sometimes thinks. So I've been through you know, almost celebrating my ten year tenure, but that ten years, I've been through two company acquisitions.
So my company got sold and then it got sold again. So and I've stuck around with it for almost ten years through the whole thing, and you know, there has been some of that loss and application that had spent four years working on. As soon as the new company acquired it, they said, day one, 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. Oh 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 twenty, 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 have a family, it's easier to move on from that stuff. And I think it's also good to have more people like that in the industry that are just like that, have kids already, that 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 Rayls 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 is really helped. I worked 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 into 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 gained 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 going to delete this entire thing and start over. It's so hard, though, I mean, 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 six seven 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 the wait, okay, it's somewhere sash. What if you need it later, just get stash and I see you. Oh no, no, no, we don't. We just get stash pop or whatever command you used to delete
the stash, which I don't know. And I'm in awe of the kind of distance right like, as you said, like they have the maturity of being like, Okay, my brain did this, My brain can do this again, valuing knowledge that you acquired. It actually kind of reminds me of a college art class I took where early on in the course we had to produce one hundred pieces of original art in a week, and we brought them and turn 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 Andrews's lesson. 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 now here, this is who I am and stuff, and he would look at it and then he would just tear it up and say, good, do it again, no feedback, no pointer, or 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, you just
tear it up, 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 implies 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 any kind of project creatively. It's like, ah, 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 saying, 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 end of Code School was I've nurtured a few people, and a few people have nurtured me, and we're all like kind of like seating each other and pieces of the spirit of code School and things like plural site, like GitHub actually like other places where so Joel Taylor, who's on my team works at task for It 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 sucks, but this was awesome, and this is an awesome thing that we did. Often it's about
people's stuff and more and more of the code stuff disappears. There's a few little trickery things that you're like, oh, we had we figured out a way that was nice to do x ra Y, but it's rarely the code that's like, oh, this 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 now after doing Ruby for a while and then uh, now, I just
want to give him a little shout out. Really enjoyed it. Yeah, that's actually how there'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 meal learning Rails, when I was still kind of like a front end focus web designer type person and still in school. So I did that little beta before they actually released Rails for Zombies, I think in the fall of twenty ten, and then in
early twenty eleven they launched a codesc subscription service. Man at the end of twenty eleven beginning of twenty twelve, I started at cod school. So I literally learned rails on rails for zombies and then worked on rails for zombies. So a 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 full Sell University when I went to school,
and he was within a few months. He was like good enough, but he'd 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 nbc orm's, you know, web development, and saying to myself, I will probably never understand this because I think one episode I've listened to of some Ruby on Rails podcast talking about controllers and we're thinking, like this word makes nose. 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. As an English major at the time, that's the only qualification I had used to drive me crazy and I really really thought, I'm just gonna learn a little bit about whatever this is, but I'm never going to be good at it, And then it just makes so it's so weird to see your name and people at comferences going like, oh, I learned rails from you, or I learned our respect
from you. What. I can definitely sympathize with that because in college I listened to this podcast all the time and learned so much but also new almost nothing from it. I was like, I don't know these words meaning they're using all these terms and yata, and now looking back, I know what those words mean, and now I'm here. So you know, it's just a 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 do this thing called a time machine, so 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 you your sense of self worth back six months, back a year, five years, and ten years and realize this thing you thought impossible. Now you do it like on a daily basis, and it's not even a big
deal and it doesn't even phase you. But it's good to do that because I think, David, you're talking about the sense of self and how much or worth and how much you derive from the work you're currently doing, Like how much worth you derive from now? How much worth you put in it?
And I think it really helps to go back regularly as a kind of like a self care exercise to make sure that you you acknowledge and appreciate how much you've learned and how far you've gone despite things starting an ending here and there, like school ending or a job ending or an app ending. Absolutely, I think I was thinking about I've heard talk about rails itself and say, and he's acknowledged, what if this is the best thing I'm ever going
to do? Yep? Wait, so I guess in the 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's 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 terms from his perspective, So the comics similar to dch like, I thought those thoughts of you know that this is the best thing I'll ever do, and and
then it ended. And d is lucky because it didn't end for him, and he's 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 change my life, right, And people have told me the same thing about Codeschuild. They're like, ah, 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 you are. It's back to the planning thing or seeing ahead, like you don't know if it's going to 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 Kraals. Yeah, I've had people tell me some of the same things about the podcast, that the podcast change people's lives, and it's it's interesting because in some sense I kind of see where they're coming from, and in the other sense, it's like, yeah, but we just kind of 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 it all come down? And yeah, so I think some credit
is deserved. But on the other hand of me, people went and did the work, they figured it out, So I don't know. Yeah, I think too. 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. All Right, Well, we're kind of getting toward the end of our time, and I think we've kind of minded this topic for now, so let's go
ahead and do some picks. Nate, do you want to start us off with picks? Sure? So I just recently listened to just yesterday the keynote from rails com from DHH again, and it's it's really just fantastic. 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 I 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, all right. So yeah, I have two picks. The first pick is I coughed up the money after seeing the like six or seventh Apple display because I've been in the market for one bowels, holding off until I saw what Apple was going to do with their six K. I'm like, screw that.
I'm not going to buy that. So instead, I got the five K screens from LG with the Thunderbolt three connector, and they are amazing. The quality on them and stuff are really nice. And you know, after seeing a six thousand dollars price stag, a thousand bucks 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, no 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 six K monitors and how much they were going to cost. Well, it's the stand that actually made people go CROs. Yeah, people, people almost booed. If you watch the keynote, it's very interesting because I watched it late after everybody watched it, like almost a week after, and there's an audible like what when they announced a thousand dollars STAN for a five four or five
thousand dollars 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 six thousand dollars. People are be like, yeah, sure, it's Apple, But if you split the two, it just sounds insane and it makes sense. You know, almost would have been better if they said it costs that much and people remove the stam in the cart and see, oh wait, it's a thousand dollars cheaper. I think they would have as a
negation. It would have been or subtraction would have been way better for people to discovery. I'll just get a two bite four and some nail. I mean it kind of kind of looks like that. All right, 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 ninety nine cent 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 nutrition has actually recommended them. So yeah, that's my pick. Nice, I only eat sardines to gross my kids out. So I'm going to jump in with a few picks here. So one 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 going to 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 Food Fight Show, which is a devop show that was put on by Nell from Chef and Nathan
who used to be at Chef and is now at Google. Then Nell is helping us pull this one together and get a rolling so I'm excited about that. And she's been on the show before too, so I'm going to pick that. I also want to shout out about plural Site. They've got a ton of great courses there, so if you want to 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 plural site offers as well, so that's definitely worth doing. Yeah, and then two more picks really quickly, just because I'm excited. My wife 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 butcher Box. And butcher Box 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 yeah, I feel like you had to because of the sardine pick to balance things out a little bit. Sardines. I don't think of sardine's is meat as much as I think of like steak and port Anyway, Yeah, ZII jelly at the Month Club probably sorry the National opens chuck there. It
wouldn't shock me at all at this point if there's a jellybox. But yeah, so yeah, I'm excited about that too, So I'm going to pick that. And then when I came out here, I booked my hotel through hotels dot com. So if you're looking for a way to save some money on a hotel, that's a great way to go to Olivia. What do you picks? So I'm going to 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 trying to be kind of conscious, I actually made It's going to be kind of like a half steff self pick. There's two things I don't like. It 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 like just crap everywhere. I tried 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 want to be contentious. It just has exactly what none of the substitutes to milk have, which is like a little bit of fatty content in it in it to make it like substantial, and it works pretty well with coffee. There's a barista addition for people
who like 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. Oat Lea's a little bit more like two percent 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 ribbi specifically, it's my favorite cut, but when I eat burgers, i'm kind of curous. Like ground meat in general, 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 intellectual curiosity, try it out, because I've discovered that I don't like alternative fake meat stuff, but things that are good and that you used to replace ingredients with, not just to pretend that they're meat, but to be like, hey, this is also good. A lot of the impossible burger beyond meat all that stuff is pea based, So this is pea protein and PA has kind of like a dirt, kind of like similar irony
taste as meat red meat. It's not going to be 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 wastefulness kind of like sustainability angle. I made a little website for Earthday called Horizon zerowaste dot 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
that's actually marked down. I'm pretty sure if I remember correctly, there's at the bottom you can see there's a link to the repo and it's just a list of things you can do as alternatives to things that are wasteful. So, for instance, bottle of water is just straight up it makes no sense, like just there's so many ways to drink water in metal bottles like this
qrsicle bottle that I have. It's an Orlando based company that makes super good Zoji Roushi is a Japanese company that makes really easy to drink from mugs that you don't have to unscrew and things like this. Carrying around a water mug or 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 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 a little type of keyword box at the top. Anything plastic, you can see alternatives like metal, metals cool. You can smelt it and you can turn it into something else. Plastic not so cool. A great examples 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 Techi picks. I'm just gonna go go through them really quick. I'm an amateur photographer and for years I try to fight Apple Photos
or like work with it. And probably they're going to improve it with the new macros 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 in like two hundred and fifty thousand shots in fifteen years or something like that, so it takes a lot of space. I want
it sync across devices. Turns out Adobe was there a while ago. They're still there, and Lightroom CEC is one of those things where I'm not paid to say this, but as someone who's just a software nitpicker and a photographer, they've kicked ass on light room C. You see. It's efficient. It uses sql light as a kind of like a local storage database, but it's all kind of like Canonical in the cloud based, which means it's always
sinked 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 thing and it works surprisingly well. It's fast, the editing is seamless. You can do a lot of things with a keyboards. It's really impressive, and I think they have like cheap or free tier plans for thirty
days or something like that where you can try it out. I iPhone app, macrosapp, and pretty much every platform. Even the web app is great. Well, what's your preferred camera? My camera's nuts. So this is not a recommendation because most sane people would not spend that much money on a camera. So I have a Sony X one R two, which is a full frame fixed lens camera that's a thirty five milimeter lens F two point zero Zeiss lens on a basically the same sensor as the mirrorless A seven R two
by Sony, which is the big fancy Sony DSLR. Basically it's not DSLR, there's no mirror, but it's one of the best there. The sensor is the big thing, big ticket item. Is just an incredible fifty mega pixel sensor or forty seven megapixel sensor. And it's a full frame camera, so you get all that, you know, soft focused stuff and Bok booka and yeah. So if you like photos and stuff like that, it's it's good stuff, very cool, all right. If people want to find you
online Olivia, where do they go? So O L I V I E R L A C A N dot com. That's my email to hi at me. Uh that's the same for Twitter, O L I uh oh wow, I'm trying to spell my name, and I'm 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 like keep a change log and uh yeah that's me. Nice all right. Well, thanks for coming and talking to us, Thank you
for having me. All right, We're going to wrap this one up, folks, and we will be back next week.