Co-Founders, Layoffs, Ruby Memory, Docs Product

CJ: Welcome to build and learn.

My name is CJ.

Colin: And I'm Collin, and
we're back to catch up.

How's it going, CJ?

CJ: It's pretty good.

We usually record sort of midday, and
for me this is a little bit later in

the afternoon, so yeah, starting to
wind down for the evening, and since

it's the middle of winter, it is pitch
black outside, which is very, a very

common thing in New England apparently.

Colin: Yeah, I love that my camera
is daytime, and yours is nighttime.

CJ: Yeah, it looks like, yeah, you
look fresh faced and bushy tailed

and ready to rock for the day.

Colin: I do have two very large Elgato

CJ: lights.

Oh, okay.

maybe that's it.

You've got great lighting.

Yeah.

Colin: a little bit.

CJ: Is that window that's
in view of your camera?

That's an actual window, right?

Colin: This thing?

CJ: the one on the other side.

Oh, I

Colin: Oh, I see.

yeah, there's a window this way.

CJ: not like a fake, faux light thing.

No, okay,

Colin: Yeah, and this is not going
to translate well to podcasting, but

these little things behind me are a
project that I haven't finished yet.

we're going to make that door disappear.

CJ: yeah, it looks like maybe some
sort of curtains or something, like

Colin: they're actually like
sound absorbing, wood panels.

So they're like walnut.

Fronts with sound absorbing on the back.

You, I think you see them in all
the desk setups and all the YouTube.

the new YouTube thing these days,
but I'm also a sucker for them.

It's very I don't know, Whiskey Room

CJ: I don't know, whiskey room vibes.

Yeah, and it's funny because

Colin: Yeah.

and it's funny because this room
when I'm on my work calls, people

are like, what room are you in?

Because there's actually
three doors behind me.

And so everyone's we don't even
understand why this room could even be

in your house that you have three doors
because one goes to an HVAC, one goes

to a patio and one goes to the hallway.

CJ: HVAC, one goes to a patio,
and one goes to the hallway.

Roaring and so I put all these giant
blankets on the wall on the other side

of the wall that are like absorbing
all of that roar And it helped a ton

with just like sound quality But I
also fight with the piano which is like

right above me So the kids will be like
doing their piano lesson mid meeting

or whatever and yeah, it's interesting

Colin: Yeah.

People like moving blankets
because they're wool.

CJ: I

Colin: picked up like a
target weighted blanket.

It's like a 50 pound blanket that I
have just pinned to this other wall.

a lot, I mean it doesn't look pretty,
but it's cheaper than a lot of the

sound treatment stuff out there.

CJ: there.

Yeah, mine are just giant moving blankets.

They're just like two huge moving blankets
that are, yeah, tacked up on the wall.

Colin: Yeah.

Cause these things are cool behind me,
but they're like, I don't know, 300

for two or two to four of them I think.

And this blanket was like 20 bucks.

So it's easy to spend
money in AV stuff for sure.

CJ: West Boss, did like a whole series
of videos about how he built out his

office and got very technical about
how sound transfers between things

and, buffering, like even the wires
in the walls and stuff like that.

It's whoa, that's,

Colin: We should get him on for a
show just on that because I think

the three of us have done a lot

CJ: Yeah, just trying to like
soundproof things is interesting.

so I posted on Twitter the other day.

one of my sons is in swim team
once, once or twice a week.

And the other, my other son is at
home, didn't want to do swim team.

And we were trying to
figure out like what.

What kind of activity could we
do that would be interesting,

engaging, and like enriching for him?

And he loves telling people the news,
just like anything that he learns

about that he finds interesting.

He'll just, as soon as he learns it,
he has to run around and tell people.

And so I wanted to start teaching him all
these different tools for journalism, and

just like how to go and talk to people.

on the internet through podcasting
or through video or through blogging.

And so I put together this super
short little course on Google

Classroom where there's all of these
little assignments for him to go

through and build out a podcast.

And so it's make a title and make a
cover art and come up with a description

and come up with an audience and then
I followed along with, Descript's

how to start a podcast flow, but
then I boiled it down to what would

this mean for a fourth grader?

And what is this what kind of
like stuff can we also do with AI?

So really awesome tools out now.

I don't know if you've seen, Google's
like music effects labs things.

You can do text to music so you can
GPT generate a song basically that they

can like use in his intros or whatever.

So he's generated some intro
and outro music and, started

doing some recording today.

So it's been really cool to watch
him experiment with that and fun

to just share what I've learned.

Colin: Podcasting is such a good
thing for anyone to play with.

Cause you gotta, you get
to just play with audio.

You have to think about what
you're going to call it.

You get to write a little bit, get
to do the description, the graphics.

it's a pretty good project.

CJ: project.

Yeah, it's fun.

once it's up and live, I'll plug it
in a future episode so you can go

listen, yeah, I think it'll be about
gaming and Pokemon and stuff that he's

interested in, so it should be good.

Colin: I think that's the way

CJ: all podcasts start.

Tell

Colin: this other tweet that you had.

You were looking for, kinda like
non technical co founder type

CJ: other tweet that you had.

I found a website called something
like dev meets marketer or something

like that, or dev meets sales, where
it's At the time it was like, okay,

Cupid for founders where you're do
you know, founder dating almost?

And like founder match, or
like Tinder for founders.

And I was just curious, like how people
are finding co founders because oftentimes

you hear from YC or you hear from venture
capitalists that they want to invest in

companies where there's multiple founders.

I'm like, how are people finding
who they're working with?

so that was the first layer and the
second layer was like, it's the new

year and I've got a million ideas and
things that I want to build and, In the

past, a lot of stuff, I try to get it
off the ground by myself and I think it

would work much better if there were,
someone by my side with complimentary

skills, just like helping hack and
promote and, mostly just like marketing

and sales and talking to customers and
validating different ideas and telling me

like, that's stupid, don't go down that
path or Hey, that's like a good idea.

Or just being a separate, set of
eyes and some, Yeah, I don't know.

Some interesting things and
conversations fell out of it.

But, one thing that interests
me about this process is that

it is very much like dating.

You can't just find someone
on the street and say Hey, we

should be like co founders.

Let's go co found something like
oftentimes at hackathons, right?

You meet up just like random people and
you try to get something off the ground

in the weekend for startup weekend.

But, I think there's a lot of
like compatibility and personality

type situations that go into this.

I don't know.

When you did CloudSnap, how many
co founders were part of that?

Colin: there was just two of us to
start with and at the time I was the non

technical but more technical than most co
founders so I kinda took on the CEO role.

And then Chris took the CTO role cause he
was definitely more technical than I was.

and that did mean I rarely wrote code.

Like I was reviewing things and
doing a lot of prototyping more.

I was more PM going out and talking
to customers, trying to make sure

that we had something that people
would want to use and then know that

when we build something, someone
actually would be there to use it.

versus sometimes people.

go off and build a thing for years
without ever showing it to anybody.

and that, that can be really tricky.

I think what you're talking about
is being a technical person looking

for a non technical co founder is
really interesting because I think

most people in tech have probably
had people come to them with ideas.

And that, there's, that happens a lot.

And it's really hard to go through
and figure out who's really serious

about it, who's put their own skin in
the game, They're not going to have,

I don't necessarily think they should
go and try to learn how to code and,

had varying degrees success at that,
but they've at least figured out,

they know what their strengths are.

They know what they're lacking.

They know what they bring to the table.

And that might even be like,
I have customers ready to go.

If you can help me build this type
of thing on the other side of it,

it's okay, we know we can build
lots of things as technical folks.

What are those gaps that
you're talking about?

And even just like when you're building
something, you just don't have time

to also go out and talk to customers.

CJ: Yeah, and I'm not saying that,
technical co founders shouldn't

talk to customers necessarily.

I just think that, yeah, that's

Colin: They need

CJ: yeah, really bad at in the beginning.

And, yeah, they absolutely need to.

And.

Going back to just like
being a creator in general.

I think oftentimes we're, maybe I'm
speaking for myself that I'm like afraid

to launch something or share it widely
because I'm not super comfortable with it.

And maybe when you are working
with someone else, they can be

like, Oh yeah, that's totally fine.

Just like ship that and let's get some
eyeballs on it and start getting feedback.

And maybe they're more comfortable
sharing it because it's not like

their own creation, in a way.

And so it gives them a little bit more

Colin: Having that divide helps.

It's like a lot of people don't like
to edit their own sounds and their

own audio and podcasts and stuff.

And it's it sounded great.

And you're like, Oh, I can't do this.

but what you're talking
about is very true.

Like YC and Techstars and a lot of
these folks, they almost always look

for people to have a co founder.

Because their argument is, if you
can't even convince one person to

come along on this journey, like,
why would we put money into it?

CJ: it?

Colin: but at the same time If you can
pull off everything and even better

if you could do it without investment.

I'm becoming more and more
of the don't go the VC route.

more of the indie hacker bootstrapped
approach but, if you're going to be doing

that then it does help to have someone
else who's, the other side of that coin.

with the coworking space
it's a little bit different.

But myself and the other owners are a
good, push and pull on, I get a little

excited about something and then they
bring me back to earth, which can help.

So we want to be pushing forward,
but it's always good to have a little

bit of tension on that line so that
we don't just fly off into space.

CJ: Yeah.

The other thing that has been on my mind
too is just in general, that co-founder

fit, like how do you find someone who has
a personality that gels well with yours,

and where you almost kinda have to have
Side gig values aligned with a vision

that's aligned for okay, we're going to
work on this with, nights and weekends

with no payoff for, maybe even years.

And then once it gets off the ground,
maybe we go full time or I don't

know, like, you know what I mean?

Like, and trying to find someone who,
yeah, shares those values and also can get

excited about the same things that you're
excited about is, yeah, it's interesting.

Colin: Yeah.

There's an episode that we can
link to from the Hammerstone.

Dev podcast, and Hammerstone was a team of
Aaron Francis, who we've mentioned before.

And, Colleen, I am blanking on her last
name right now, but they have chosen

to separate and Colleen's going forward
with Hello Query and Aaron's focusing

on the things that he was doing at
PlanetScale and some of his other stuff.

And it's a really good conversation
because It's them having a good

breakup on a podcast they finally
are starting to feel that like

customer fit with their product,
but it's not the end of the journey.

It's the very beginning.

that little bit of product market fit
means there is going to be months, years

of work to be done, nights, weekends,
whatever that looks like, especially

with families and things like that.

And Aaron just kind of like, I.

Can't do that right now.

And it's also very good
to be real about that.

Cause sometimes co founders will take
their other co founders for a ride

when they aren't being truthful about
how much time and space do you have in

your life for these kinds of projects,
which is, it's good to be open about.

CJ: about.

There are a lot of really awkward
and uncomfortable conversations

that happen at that early stage.

Even After like a startup weekend
hackathon, I've had people like, pushing

really hard in certain directions.

I'm like, yo, we just
worked on this for 48 hours.

I don't care.

do what you want with it.

Colin: Yeah.

I start off weekend.

Is an interesting one.

I haven't seen those as much lately.

I don't know if they've died off or
just gotten less popular, if you win,

I've fallen into it where we won one
of the startup weekends and it was

like, okay, we're going to try this.

And we took a little bit of seed
money and we did not get very far.

But it's hard because, those, that team
was put together on a weekend and they

all happen to be in the same event.

There was a little bit more
intent there, rather than

meeting someone at a Starbucks.

but there's a guy who reached out to us,
I think it was just through Twitter and

the dev meetup, but he runs remotejobs.

com.

And He's the kind of person or he's
like the non technical co founder,

but he's teaching himself how to code.

and he's hacking and doing the, using
the templates that are out there,

using the job boards and stuff.

And he's built himself that
nomadic, remote, lifestyle that a

lot of people like to talk about.

and I think he's doing
that without co founders.

So it really depends on
how much space you have.

In your life and all of that
because, I could try to make the

awkward segue here of what happens
when you take too much money

CJ: and

Colin: grow too big.

CJ: there's really

Colin: there's a really good Silicon
Valley, link that we'll put in the

show notes too, but yeah, this week
has been a rough week for tech layoffs.

I think especially for companies
that grew a lot in 2020, 2021.

this week we've got, what, Twitch,
Google, Amazon, Unity, and then, we

just actually had layoffs today at
Discord, which I can't talk too much

about, but, by the time this comes out,
it'll be almost a month behind us now.

rifts across the board, teams getting
smaller, all that kind of stuff.

CJ: that kind of stuff.

Yeah, I thought, the bleeding
was over and that teams did

their reset in 2023 and that.

we were going to go into 2024
with nice, healthy organizations,

but totally not the case.

And I don't know, yeah, I don't
know what the deal is or how

long this is going to last.

It's a huge bummer, for everyone.

I guess the other, piece of this
too is that, like, how much is

AI, impacting these jobs, right?

I also, outside of These sort
of like tech specific jobs.

I also saw a bunch of people getting laid
off from like movie studios and animation

studios where they're like, yeah, we're
not gonna need any animators anymore

We're just gonna use like AI from now on.

It's

Colin: Yeah, this role this week
has been pretty content focused.

So a lot of gaming industry, right?

Unity Prime video, some Prime Studios
folks So a lot and I think my friend

who runs a lot of things in the
tabletop RPG space Has shared that

like it's flowed down where it's like
gaming's been hit Tabletop things like

D& D are not as popular or selling
out as much as they were before.

You know, there's groups like Critical
Role that are doing really well, but kind

of gaming, which I think is interesting.

I don't know if we just gorged ourselves
on content during the pandemic and

everyone staffed up because of it,
thinking the good times were never

going to end or what the deal is.

and a lot of people are upset
that movies aren't doing well in

the box office, but I don't know.

I don't know if those
are related whatsoever.

I think it's just been like I'm excited
to go see Dune, still in the theaters.

CJ: it seems to like a lot more
people are creating content.

we're making this podcast, right?

And there's a ton of people who
are making TikTok videos and

YouTube shorts and whatever.

And maybe just the sheer
volume of entertainment.

is getting to a point where, the big
studios aren't able to keep up as much.

It's almost in the same way that
new, newspapers mostly lost all of

the wind beneath their sails when,
blogging and articles became popular.

I don't know.

but, yeah, it's a huge bummer for
anyone who's losing their job,

Colin: Definitely.

Yeah, if you're looking for something,
we got, we'll put some links to some

remote jobs and some tech job links in
the show notes, because I've had a lot of

people coming to me asking, what jobs I
know about, somehow I've gotten that as

like a reputation as the person to go to
when someone's ready for another job, but

CJ: view you as a connector and
someone who knows about opportunity.

Yep.

Colin: For

CJ: Yeah.

so Yeah, similarly, or along the same
lines, we are hiring at Craftwork

still, so we've got some super promising
candidates that we're talking to

this week, but if you are interested
in writing TypeScript or Ruby and

Rails and React Native and doing some
machine learning stuff, we are, yeah,

we'll likely be hiring at some point
when you, when you hear this later,

Colin: Very cool.

What are you, building this

CJ: this week?

Gosh, it's been a really productive week.

I was sick last week and so I felt
sluggish and unproductive and this

week has been super productive
and I'm, yeah, it feels great.

a lot of it has been API integrations.

One of them is with this company called
Deputy, which is a platform that we

use for scheduling and timesheets.

it's how the crew clocks in and out
and the automations we're building is

so that we can tell customers which
crew members are going to be coming to

their house when the project happens.

And we can also build out
like some calendaring and

scheduling tools internally.

So that's been super cool.

we also use a tool called Post Hog,
which is for like product analytics.

They actually have a
kitchen sink type situation.

They do, yeah, product analytics,
they also do a B testing.

They also do like feature flagging and
then they separately have almost like a

business intelligence suite where they
have like data warehouse type situation.

And, It's, yeah, so an interesting tool
and we've been using them for tracking,

like front end marketing analytics
and, UTM params and things like that.

And what we're doing now is piping back
different project and conversion type

events back into post hogs so that we
can measure like the full pipeline and

start to get some proper attribution
and figure out, which marketing channels

are working and which aren't and.

yeah, that's been pretty interesting.

So

Colin: Nice.

Yeah, I like Posthog because they've got
all the data that you're, like, gonna want

in one place so you can do feature flags,

CJ: rather than

Colin: trying to connect two things
together and say, show this to

people who've done this thing.

CJ: Yeah.

It's been, pretty good product so far.

Another thing that's been really
interesting as we're researching

business intelligence tools is.

How many have Jupyter Notebook style
interfaces now built into them?

I think we looked at hex.

tech and posthog and, Supa or
Meta, Metabase and a few others

where it's like, Oh, you can write
SQL queries and get back a table.

Or you can write Python to
interact with that data that was

just in like the previous cell.

Very cool, interactive
business intelligence stuff.

I haven't messed with business,
like BI suites since college.

like Microsoft, BI or whatever.

Colin: Those ones are interesting
because it's like, everyone needs

one and when you get big enough, you
gotta go with the big enterprise one

and there's a bunch of money involved.

I remember.

At Strava, I think we started out
using segments and they just quickly

got too big for segment you still
got to put that data somewhere.

It doesn't get stored in segment.

And so they were using something
called Snowplow, which they self

hosted and it's like an open
source, BI tool in that vein of like

customer events and things like that.

All sorts these days.

CJ: totally.

Yeah.

And it's do you want a data warehouse or
do you want a visualization thing that

will just let you build dashboards and
charts for your existing data sources?

Or do you want, yeah, these notebook
tools where you can have data scientists

write all these different queries.

And yeah, it's definitely
been a learning curve there.

Yeah,

Colin: Yeah, sending emails every
fifth time someone does something,

stuff like that, where it's oh, I
don't want to keep track of that.

CJ: yeah.

yeah, it looks like you're working
on some, some more Docs stuff.

Colin: Yeah, so I'm stuck in DocsLand.

mostly about things I can't
talk about yet, but I can talk

about what I'm trying to do.

we have a thing in, we
have our docs in a repo.

And that's all public.

So anyone can contribute
to our docs today.

And we have another thing that's in
another repo and I have docs in there.

And so I want to basically hydrate our
public docs with those other docs and

make sure that everything plays nicely
and that we don't have like drift between.

The two, so if you think of it as
like an SDK type thing, how do we have

versions of that, docs of that, but
then we have the API docs, so very

similar to when you were at Stripe,
you guys had the Stripe SDKs, the API.

Has versions, all that kind
of stuff changes over time.

So in the discord docs, we don't
actually really have a good

versioning system in the docs itself.

It's more look at the table.

What version are you on?

That is what applies to you.

So we aren't going to have versions
anytime soon, but I'm just trying to

think through, like, how do we not
end up copy and pasting documentation?

How do we not have drift?

How do we not make it,
manually corruptible?

So that's what I'm working on.

CJ: on.

Nice.

Yeah, we've been talking a lot
internally about generating OpenAPI

specs so that we can consume it from
our React Native app and our Next.

js frontends.

And I've been surprised that the
tooling isn't really there in Rails.

There's Oh, or like to, it's not there
to like automatically do it for you.

I expected you could just drop in
a gem and say I'm using JBuilder.

And then it would just figure out
all the different types and be able

to build the whole spec for you.

But it's not that easy.

The state of the art, as far as I can
tell, is you have to write tests in

our spec that then will map to, the
open API specs that can be generated.

But in order for those to get spit
out, you actually have to write the

tests and we should have the tests.

And I'm not discounting that in any
way, but it feels like a painful

way to keep them in sync is to
have to constantly write tests.

Colin: Do you then have to annotate the
tests or do you annotate the source,

the main source code for things like
descriptions and labels and categories?

Because that's the thing, we have
an OpenAPI spec today, but we

haven't finished, I think it's
called tags and descriptors, right?

we use one of the tools to generate,
CLI, but because there's no categories

and everything, it's here's all the
functions you could possibly call.

And so we're going to be adding tags,
we're going to be adding descriptions

so that, that CLI is more useful.

especially when you have, start to
have endpoints that look the same or

get called at a different context.

CJ: in different contexts.

Yeah, so within, I'm pretty sure
you write it within the test.

but I'm not, yeah, not sure.

Colin: That would make sense because
then like where the spec is generated

from all comes from one place.

CJ: Yeah.

So the default when X is using our
spec, we're using many tests, so

there's going to be some differences
there, but like when you say, okay,

describe blah, it blah, or like it gets.

thing, then I think like the test
description can be used as like the

body of the whatever you're describing.

But yeah, I'm, I know there's some sort
of, yeah, some sort of DSL that's in

there that's like really tightly coupled.

And if you want it to, generate good
public facing documentation, I think

it'll be challenging to maintain.

Colin: then you have to flag each of
those if they're public or private.

You have to flag them if they're
going to be in certain versions.

there's a lot that goes around this.

CJ: Yep.

Colin: if you want to have examples, if
you want to have examples that can be run.

I guess the test itself could be the
example, but it's not always that clean.

Yeah,

CJ: you generate the spec, then you
can use the R Swag UI and R swag.

API.

Gems and those can just take in the spec
and then they can make it so that you can,

make test calls or whatever directly from
the UI, like Postman or something, but,

Colin: Yeah, ReadMe has a bunch of
really good, Libraries for this in

JavaScript, but they have an OAS to
snippet, which will take the, spec and

turn it into a code snippet for you.

CJ: a code snippet

Colin: Like a curl, you can say curl,
Python, whatever you want it to be.

and then there's another one that
will actually let you like run it.

So that you can do the playground style
type stuff and inject your tokens into it

CJ: type stuff and inject
your tokens into it.

Now that we're on the outside, it's
oh, that's actually like super helpful.

Colin: Yeah.

I'll send you some things cause
I've seen, I've been playing

around in those tools as well.

And there's one where you're like, when
you generate the whole JSON, it's pretty.

CJ: alarming.

Yeah.

Colin: then there was one where
that'll convert it to YAML, but also

put it in folders of each resource.

So you

CJ: So you can

Colin: see it better
and you can go edit it.

And then when you're ready, you can like
have it rebuilt back into the single file.

Cause it's not fun to go
navigate that, by hand.

CJ: right?

If you look at the.

the OpenAPI spec for the Stripe API,
which is publicly available, it's on

GitHub, slash Stripe slash OpenAPI.

it's insanely long.

the YAML files are just monstrous.

Colin: And yours is in YAML.

I think ours is in Jason.

CJ: JSON.

Yeah, I think the repo might have
several versions, but the, again, because

Stripe isn't built with Rails, it's
built with, a bunch of homegrown tools.

The place where you describe what you
want the resource to look like is all

in the same spot as, the actual API,
endpoints and resources are defined.

And in that world, your documentation
and your implementation are in the

same place, and it was very handy.

It was super, super nice.

yeah, I was expecting and hoping for
something similar in Rails, but No.

Colin: Yeah.

and there's some other
tools that will decorate.

Open API.

So once you generate it from
your code base, you can have

another step that decorates it.

So maybe, you convert those more
developer friendly descriptions

into localized And, dev marketing,
strings and stuff like that.

CJ: That's cool.

Colin: Yeah.

CJ: Yeah, I was half thinking maybe we
ought to just feed all of our models

and all of our J builders and all of our
routes into Jet GBT and just be like,

Hey, generate an open API spec for me.

He's done this huge

Colin: might be faster.

You never know.

CJ: Yeah, tricky to maintain
something like that.

And I don't want it to fall out of sync.

is the, are the docs that you're
working on, something that

would have an API behind it?

Or is it like more SDK docs?

Colin: it's something completely new,
so it's not like an SDK for the API.

It's different.

But yeah, even now, like our own API
specs, some people are starting to use it.

It's still very much developer preview.

We tell people not to build anything
with it because it might change.

especially around those like circular
references, the schema references

or errors, stuff like that.

and we're trying to make sure that
like our types match the types That you

expect in this spec and things like that.

there's some things
that can be many types.

That's always fun or a
bunch of union types.

CJ: Yep.

Very tricky.

Yep.

Colin: We love some APIs though.

CJ: yeah, exactly.

So another thing we've been working
on a lot, craftwork is trying to get

our memory bloat down a bit we're on
render and we're still very small,

tiny startup, we've only been running
our rails out for about six months.

And so we hope and expect that
maybe a four gig box on render

should do just fine, but we
keep bumping against the memory.

Like sealing there.

And so the last couple weeks I've
spent just like learning a ton about

how memory management works in Ruby
and Rails and just like keeping

an eye on renders memory chart.

And.

One of the things that I learned
was that you can just call gc.

start.

There's like this gc
module that's available.

and that will kick off
garbage collection for you.

We had a couple of jobs where I was
like, Oh, at the end of this job,

maybe I ought to just kick off gc.

start because it's, uploading
a bunch of images and creating

a whole bunch of stuff.

But, so that was interesting.

And then.

Ruby comes, out of the box, Ruby
uses an allocator called malloc.

It's like the default
allocator, I think, for C.

But you can switch that to
different allocators, apparently.

And one of them is jemalloc.

Which, on render, you just
set an environment variable.

That points at some SO thing and then it
starts back up and is better at memory.

handles memory fragmentation better and,
yeah, just helps avoid bloat a little bit.

I was also super excited
to upgrade to Ruby 3.

3, which we did, and that actually
gave some like pretty noticeable, like

speed improvements, which was cool.

And then, yeah, we, so we use, Sentry
for error tracking and alerting.

Shout out if you want
to, sponsor the show.

But the tools that Sentry
gives you for looking at memory

management don't work on render.

render is agreed to support the
agent that comes from Scout APM.

And so we've been exploring and using
the free trial for Scout this week.

And it is pretty cool.

seeing all the different, background
jobs or controller actions and then how

much they increase the memory ceiling,
Based on the methods that are called

or whatever and you can see traces and
they give you a lot of details about

here's how many allocations that were
made as part of this and here's your N

plus one queries and here's like specific
methods that are taking a long time.

so still learning a ton about Scout
APM, which, yeah, it's been pretty cool.

to learn about, but yeah,
we still haven't, we still

haven't completely solved it.

But

Colin: There's been like a whole new
discourse around the cost and time around

using things like Vercel and Render and
Fly versus running on a box yourself,

or I know that 37signals has moved all
their stuff off cloud, which It's probably

just their own cloud somewhere else.

It's just off public clouds.

They're not running in
DHH's closet somewhere.

but I don't know.

I still, I mourn the Heroku
days of just slapping something

up and getting it going.

And I know render and fly and
things like that are making that

easy again, but I don't know.

There's a golden age of Heroku.

CJ: Yeah.

I think that over the last six months or
whatever I've learned a lot about Render.

And it's almost to the point where
it feels like Heroku in that you just

push and go, and there's like little
things you gotta fiddle with now and

then, but, I, yeah, I still think it's
a little easier than using something

like Docker or, AWS directly, but,

Colin: having to do real DevOps and
having to go out and do all that

stuff, like, when you are a small
team, there's Pros and cons to it.

CJ: Yep.

Absolutely.

Yeah.

Colin: yeah,

CJ: Yeah.

I don't know.

it's fun.

Memory management is interesting
and I'm glad that we don't

have to think about it usually.

But, I think Ruby and Rails definitely
make it easy to suck up all the memory.

Colin: right

CJ: it's all

Colin: and usually throwing more money at
it works for a little while until you're

like, okay We're spending too much money.

Just throwing money at this thing.

let's see what's going on.

CJ: Yeah.

And oftentimes there's Oh, you could
just do an includes here, or, Oh,

you could just, exclude 95 percent
of all of the records that were

returned because you're not actually
using them in any of these results.

Or, Oh, you could cache these
into a dictionary, And then reuse

the dictionary instead of hitting
the database a million times.

yeah, lots of different little
things, little tips and tricks for

performance that we've still got to do.

So

Colin: fine tuning This
conversation reminds me.

I got some heroku emails
today from a project.

We both worked on

CJ: project we

Colin: like, the build failed to release.

I'm gonna have to go look at what that is

CJ: have to go look

Colin: Because I haven't touched
it in years, so we'll see.

CJ: touched it

Colin: We'll check in with Julie and
make sure her business is still running.

CJ: I'll check in with Julie and make
sure her business is still running.

I don't know, it's, part of me wants to
move them off and move them to render.

I'm gonna wait, I think, a
little while until SolidCue has

some time to, to bake a bit.

I don't know if you've looked into it
too much, but I'm excited to not need

to use Redis and just have you pay for
your web, you pay for your worker, you

pay for your database, and that's it,
and you don't have, this extra little,

Colin: throw things on the queue.

CJ: the queue?

Yeah, exactly.

Little thing dangling
off on the side, but,

Colin: Yeah, I think a lot of the
infrastructure stuff is why I haven't

finished my Google Calendar Discord app.

Because I'm getting into that point now of
needing to like subscribe and unsubscribe

from events and get notifications.

And I'm like, this will work for me.

But the moment we have a hundred
people using it, or a thousand, that's

a lot of notifications of meetings
and calendar events being moved

around and all that kind of stuff.

CJ: right?

Yeah, going back to the, the deputy
integration that we're working on,

A lot of that is calendaring and
schedules and whatever, and as people.

a shift goes up, and then an
employee gets assigned to a shift.

Then those shifts get published, and
keeping all that in sync, if people move

around, or they, they're, they call in
sick, or they, have to take some PTO,

or whatever, and all of those things
are shifting and changing, and trying to

keep it all up to date is, I don't know.

It's tricky, and that's one of the
things that's sucking up memory, is

okay, we're, making a bunch of API
calls, and creating a bunch of objects to

build all these automations, but, yeah.

Screencasting.

Colin: Yeah, I guess the only thing
I'm really learning right now,

other than wrangling GitHub repos,
is I've been going through Aaron

Francis's screencasting course.

So Aaron has like a unofficial
sponsored slot on this show today.

And a few of the last episodes too,
but yeah, it's really well done.

he makes amazing video content.

So it's great to see like him
take that skill, turn it into a

course showing us how to do that.

because I really want to be able
to get good at creating more video.

Like we just don't do video
content for our work right now.

my colleague has done a few
videos, but it's not like our

core muscle of pumping them out.

I think we have editors and stuff too.

So it's not that we have
to do all the work, but.

Gonna practice with my own stuff, I've
got some ideas for projects I just

want to build, but build them either
on stream or do some recordings,

CJ: Yep.

Yeah, the name of the game
is Make That Content, right?

Colin: Yep,

CJ: Is, what are the, the software
tools that he suggests in that course?

Colin: I'm still in the pre tools
phase in the course, but I think he's

doing Final Cut or something like that.

I don't think it's like ScreenFlow,
which is what I'm most familiar with.

CJ: Got it.

Cool.

Colin: So I'll check and

CJ: and,

Colin: we'll revisit this in the future in
a future episode, but I'm mostly excited

to see his shortcuts because he does a
lot of like record, stop, record, stop,

and how do you bring all those together
quickly and drop the ones you don't want.

CJ: And am recording, like screen
recording directly from Descript.

And, by recently I mean I've
only made 3 or 4 videos this way.

But, my previous workflow was like,
record in ScreenFlow, do some editing

in ScreenFlow, export, wait 20 minutes,
load it into Descript, wait 20 minutes

for it to transcribe, and then do some
more editing, apply Studio Sound, do a

bunch of stuff, export, wait 20 minutes.

It was like, oh my gosh, all of
those, Advent of Code videos.

It was like an hour a day of just
waiting on something to like export or

import or transcribe or whatever, even
on an M1, Yeah, completely working on

revamping my flow to make it as smooth
and short as possible so that it can

be like, okay, record something real
quick, get it up, get it out, and, yeah,

Colin: Yeah.

we're doing that with this too, right?

we're using a different tool.

So this will be the first episode
that we're recording with Squadcast.

So this will go straight into Descript.

I'm curious to hear if it sounds
any different, but We were already

paying for this one, so we got rid of
Zencaster, sorry Zencaster, we love you.

CJ: you.

Colin: but we're gonna see how this works.

One last tool, cause I was doing the
same, we would export it from there, then

share it in Dropbox back and forth to get
it into Descript, and Are you editing?

Am I editing?

It's just let's get this out
the window as fast as we can.

CJ: Yeah, right now it's just fun, right?

We're just doing this for fun.

We don't have editors.

We don't have anything.

We're just hanging out.

And, yeah, so the lower touch, the better.

I think, one interesting thing for
screencasting that I started playing

with was, I think it's called key caster.

yeah, key caster, you can like
brew install this and it shows what

you're typing, as you're typing it.

And.

The goal there is make a couple videos
about, keyboard shortcuts and things

for, moving around and, switching between
windows and tabs and how do you edit

text and then move between lines and,

Colin: how do you see CJ's
Vim wizardry in action?

CJ: That maybe, yeah, I haven't
done any Vim videos yet, but,

Yeah, I think that'd be fun.

It'd be super fun to just

Colin: you're recommending that
everyone install their own keylogger.

CJ: It is a keylogger and
there's, it's funny on the GitHub

repo, it's all open source.

So the, on the GitHub repo, they're
like this, you don't want to let people

have your key access to your keyboard.

Like you can, here's how you download this
thing and go make sure that it's safe or

whatever, but yeah, it's going to become.

Just an on screen keylogger
for my videos, we'll see.

Colin: I think I will be adding that
to my personal computer, not my work

CJ: computer.

Yes, yeah, it's yeah, I don't know.

Fun stuff, but.

Absolutely.

Yeah.

Colin: Very cool.

I think that'll do it.

As always, you can head
over to buildandlearn.

dev and we'll include links to
all the show notes and resources

that we talked about today.

CJ: Alright, that's all
for this episode, folks.

See you next time.

Colin: Bye friends.