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.