Summer Fit Check, Cron Schedulers, and Sample Apps

CJ: What is up, Colin?

How's it going?

Colin: Pretty good.

How's how's the week?

CJ: It's great.

This is the final week of school.

The kids are done.

Officially done with elementary
school, which is just mind blowing.

So, yeah.

It's all intermediate
school and beyond from here.

Colin: Very cool.

CJ: Lots of end of year activities.

They've had like field days and
field trips and plays and all kinds

of stuff wrapping up the year.

And,

Colin: it's summertime.

CJ: I think they're,
yeah, it's summertime.

It is full, yeah.

Full force summertime.

Last night we did a little fire
pit in the backyard and they were

jumping on the trampoline and
just, yeah, it feels awesome.

So,

Colin: cool.

How about you?

Getting out, doing anything?

Fitness wise?

CJ: we're yeah.

Lots of.

Lots of fun stuff.

So we went for the first time ever to
visit New York city a couple weekends ago.

And Nicole and I booked classes
where you can take classes at

the Peloton studios in NYC PSNY.

So we went to went to the studio
and did two live rides with Camila

Ramon and one was a reggaeton ride.

And one was like a low
impact ride in the studio.

It was so awesome.

Like it is.

A full on experience to go there.

It's like an Apple store type thing.

And you go in and they have all these
different bike studios that when you're

inside them feel like super, super
legit, almost like movie studios.

And there's, I don't know,
it was, it was cool to see.

The instructors, we bumped into a
handful of like Peloton instructors

and the, when you see them on camera,
you think they're just normal.

Like they've got like the
same energy that you have, you

know, you're like what's yeah.

What's mind blowing is that in
person you can tell that their energy

is like level 9, 000 and they're
like just so pumped and so on.

It's.

It was really, really impressive to watch.

She was like speaking in English, speaking
in Spanish, like singing lyrics, giving

instructions, dancing, like every single
like millisecond of the entire production.

She was just like on point
and it was, it was, Amazing.

It was so cool to see.

And yeah, it was, it was tons of fun.

It also like inspired me to put more
energy into like my own YouTube videos.

Like they're not, they're not exercise
videos obviously, but like definitely

It was inspiring to just be like
way over the top and super energetic

and super, you know, enthusiastic
about whatever's going on because

I think it just makes for better

Colin: Yeah.

Are those rides that are, are those
being cast to people who are at home?

CJ: yes.

So their lives, if you're at
home, you could take it or

you can take it later to you.

Like they they record
them and take them on

Colin: that's kind of like
what we've talked about.

Like when you record anything, you kind
of have to dial it up so that it comes

across at a hundred when you're watching
it, because when you record it, if you

record it at 90, it's going to be like 70.

And so you got it to go at 130.

And that's something I
try to practice here.

The other thing that reminds me is
like the Aeros tour and Taylor Swift.

I think both Taylor Swift and then
Beyonce for her things, like they will

sing their songs on a treadmill and
just like training, cross training,

like doing, you know, taking it to 9,
000 and so that they can, you know, be

physically fit to pull off these amazing
shows and have, you know, such like.

physicality and presence in, in all
the things that they do, which takes

a lot and it's hard to see when
you see it like just on a screen.

Yeah.

CJ: don't really appreciate it nearly
as much until you're in person.

And yeah, you got glitter flying
all over the room and it's like,

Colin: Peloton is an interesting one to me
because like I, so as like, as far as like

stocks and stuff, I mostly do indexes,
but Peloton is one that I had been

buying just because it was so low for so
long, but obviously it had a huge surge.

During COVID right.

And then a lot of the cycling companies,
the tech companies around fitness and

running and all these things have kind
of taken a huge hit since, since things

opened back up, but like this experience
you're talking about is like hard

to pull off for somebody else to do.

And I see this in the hotels now where you
can just like, they have Pelotons where

you can sign in with your own account and
like you can train, you know, you're not.

Using some foreign equipment, it's
the brand and people want to use it.

Cause I think Peloton users that
I've talked to, like, they love it.

I've actually never used one.

We've talked about you and your
treadmill, the Peloton tread.

But it's interesting that it's still
like so low and still taking those hits.

I'll be curious to see,
like, if they go more.

this like experience route or like we're
moving into these new apartments and the

gym just has like a row of Pelotons that
you sign in with your account, which might

be the thing that gets me to sign up for
just the like the pass so that I have an

account to log into when I'm in the gym.

But we'll see, like, there's a lot
there that makes that interesting to

me in terms of like, now I have an
account I can take with me when I'm

traveling and still like get the gym in,
in a really easy way, instead of like

being in a city that I might not know
where to run or where to go do stuff.

CJ: Yeah.

There is, I think having a Peloton
at the hotel is a pretty big draw.

In fact, they have hotel finder.

one Peloton.

com, which we can drop in the show notes.

And it's like this tool that helps
you find hotels that have Pelotons.

And.

That was like my first
experience with it was,

going to San Francisco for three
weeks to onboard to Stripe and the

place that we stayed had a Peloton.

I was like, what the heck is this thing?

Let's give it a shot.

You know, tried it out.

And then you know, several
months later I was like, I think.

that would be really good for us.

And so we got one right before
the pandemic and ended up, I mean,

I've done over 1100 rides now.

So for us, it's just been like a
really great tool for exercise.

Colin: Yeah.

There's the gamification
element and tracking and stats

for people who want stats.

Yeah.

CJ: And yeah, there's lots of
different programs, lots of different,

there's, I feel like they, they
have something for everyone, right?

There's stuff for the, the metrics nerds,
there's stuff for the people who just

want to be entertained or have fun, the
stuff for beginners, stuff for people

who want to be super hardcore about it.

And Yeah, we've, we've just had
tons of fun and it was awesome

to go to like the Mecca, which is
like, you know, the, the the studio.

So that was, that was awesome.

Colin: Very cool.

CJ: I know last time that we were on,
we talked about RTO, the Reno Tahoe

open that you were going to run.

And I saw some pictures on Instagram.

It seems like that was tons of fun.

Colin: it was a good time.

It was my 10th RTO.

So I finally like added up all the
legs that I've run and I have like

four more slots that I have to finish.

So it'll take, if I do it the normal
way, it'll take another four years to

have completed all of the, the legs.

I think there's like less than 50
people who have done all of them so far.

So we'll see.

I think there's, I could do another,
like I've done a few ultras where

I've done multiple likes in a year.

So like if I do two ultras, I
could be done in two years, but I

think we'll take it nice and slow.

The, the doing it for 24 hours,
it took us 25 hours this year.

You only really get
like one hour of sleep.

And speaking of metrics, like you can
try to get sleep whenever you can.

It's just like people you're hyped up.

You just ran.

You are trying to eat when
you think you should eat.

And then you're like,
when should I have coffee?

When should I, it's just like your
body is like, what are you doing to me?

And you know, I've been using the
whoop band for almost five years now.

And every, every year you can see
when I do RTO, cause it's just like

the worst, like they have a joke
about the 1 percent club and that's

when you have a 1 percent recovery.

And so I got the 1 percent badge again
this year for just the worst sleep.

And you're also running.

So I had like a my run, the
hardest run I had was eight miles.

Six of it was uphill at one o'clock in the
heat and then two miles down after that.

So got it done.

Felt pretty trained.

And yeah, I kind of, this will go into
what we talk about later, but, you

know, we've, we always like to talk
about work life balance, but I'm still

trying to find more ways to get away
from the screen and, and get out there

and, you know, obviously I can just run
or use Peloton or things like that, but

these, these kinds of like tent pole
races are like things that keep me.

To it, because if I'm not
trained, I'm going to suffer more.

So having a few events planned
out has really helped me do that.

So always looking for like
the, what the next couple are.

And of course the memes and the jokes
on, on Instagram and stuff are like, once

you hit 30, once you hit 40, it's like.

It's time to run a marathon, right?

You're, this little thing in the
back of your brain, you're like,

I should start trail running.

These little things that happen
and I, I think those are probably

good midlife crisises to have.

So so yeah, if anyone's listening and
wants to get into running or trail

running or pelotoning, you know, shoot
us, shoot us any questions you have,

but really just, Get out there and
start like, you know, trail running

is like hiking with maybe a little
bit of jogging on the downhill.

So it doesn't have to be like what
you see, you know, all the pros doing

like, make it, make it your own.

CJ: So, one thing that I was
wondering about with RTO is, I

thought that they, you had like the
team follow you in the van, right?

But there's sections where
you're not running on the road?

Colin: Yeah.

CJ: so then you like run away and
then you meet up with them at a

Colin: So my leg, the eight mile one,
you can't have someone follow you.

Cause it's like a dirt road up a
mountain, it's like a mountain fire road.

So there's a few like that.

There's a downhill from
Virginia city down Geiger grade.

It used to go down Geiger grade,
which is a road, but it's like

it's super sketchy, scary road.

So now you actually go down
a fire road, which is like.

Super like just rocks and scree and
like a lot of bloody knees at the end

of it for a lot of people who fall.

But that one, the van can't
follow you obviously down that.

And then the van can't follow you
on mine for the one that I did.

You have to carry water because
it's usually during the middle

of the day for most people.

And it's, it was thankfully not as
hot as it is today, but it was hot.

It was like 85, which.

It's not as hot as it could be in
other parts of the world, obviously,

but like right now it's 95 and I
would not want to be doing that in 95.

So yeah, so for the most part you have
two vans and the sleep that you can

usually get is when the other van is
running, you try to get your sleep

in, but you still got to also go to
where the van's going to meet you.

So you have to spend some
of that time driving.

to the next spot and then, you know,
either crash on the side of the van,

like just not crash the van, but take,
take some sleep, like in a sleeping bag

next to the van at the, the trading, at
the, the switch point, or like what we

do is we rent a motel six and our van.

uses it and then the next van, van
two comes and joins and takes that

room while we go run and then then
they meet us at the next spot.

So it's nice to just have a little
spot to do a little reset and move on.

CJ: Nice.

Gosh.

So the, every year that you've done it,
have you done different segments or is

there like a segment that you run every
time or you're trying to collect them

Colin: Yeah.

So there's 12 total and I've done
it 10 times, but I've, I've done

it I've done the ultra three times.

So like I've technically run
one, two, three, like 16 legs.

So I just, I've done a lot of
the same legs multiple times.

So I subconsciously have favorites,
I guess, cause I didn't realize that.

So I went through and looked at
all the ones that I'm missing.

And now the next couple of years, I'm
going to try to knock those ones off.

So I have two legs in van one
and two legs in van two to do.

And we'll see how that goes.

CJ: Nice.

And when you say ultra, is
that a separate race from RTO

or does that just mean you're

Colin: Yeah, the ultra is so
normally it's done with 12 people.

There's 36 legs, so the ultra
is usually 8, 6, 4 people.

There was a year where one
person did the entire thing.

So that one was pretty gnarly,
they did it, they started earlier.

And it took them like two
days, I think, to do it.

So, yeah, so I've always
done it with six people.

So you end up doing double the legs,
which is a little bit more brutal

cause you don't have the other van.

So you don't have any sleep really.

Like you can try, but it depends
on how you cut up, which,

which legs each person does.

And a lot of spreadsheets, a lot of
like timing, a lot of like stopwatches

and stuff, but it's good fun.

And, and it also like, you know.

Gets me again, just to like, I am not
going to be at the computer that week.

It's like, and then you got recovery and
all of that afterwards, but good times.

CJ: yeah,

yeah, that's great.

Great way to get out, especially
in the Reno Tahoe area.

Get out and see some.

Colin: It was beautiful.

So that's the fitness update.

What are you what are you building?

What are you working on?

CJ: Oh man.

We're building a lot at craftwork.

We, I think we've talked about calendars
a bunch of different times, and we're

finally to a place where we can interact
with a calendar for building shifts

and timesheets and tracking approvals
and understanding who's where, and

just this week we started adding.

The concept of different markets,
meaning like different cities that we're

going to be able to like expand to.

So if you're looking at a calendar
for Charlotte, you'll see like, here's

all the projects that are happening in
Charlotte, North Carolina, and all of the

crews and painters and drivers who are
in Charlotte and who's booked, who's not

booked, what's happening at the project.

Are we painting?

Are we pressure washing?

Like, is this an interior,
exterior, et cetera?

So that's been pretty fun
getting that over the line.

And this is another example of a tool
where we'll sort of collapse down a third

party tool that the team has been using
so they can just use our our software.

So it's been Almost actually
it was just, just this week.

It's been one year since we broke
ground on the rails app and we kind of

did like a little Spotify wrapped type
situation about you know, like where

are we at with the code and how many
PRS we do and how many lines of code

have we written and things like that.

And it was pretty crazy to see.

Like we basically replaced
a whole chat system.

We replaced an entire, like
Google calendaring system.

We replaced a whole bunch of features
that were being used in notion.

We replaced two way email.

We replaced like yeah, like lots
and lots of these different little.

Things that and this one is like one
of the, one of the last ones is a

tool that we use called deputy for
managing shifts and timesheets and

clock in and clock out and stuff.

So slowly but surely we're building all
that functionality into the product.

And

Colin: a few, a few episodes we talked
about API platform risk and this sounds

like a lot of those things you're just
checking off and reducing the risk.

And I know we've, we've talked about
build versus buy a lot, but you know,

part of that equation is so much
of the like integration points and

the headaches that you also adopt.

And like you guys are, you know, able
to own that capacity, which is good.

And of course, as I hear you list off
all those things, I hear like the whole

internet, but Rails, Rails doesn't scale.

CJ Rails doesn't work.

How has Rails been?

CJ: it's great.

I love it.

I love working with it.

We've definitely hit a
few like scaling things.

Like most of the time at the, well,
yeah, most of the time, if something

is slow, it's because we have some
naive query that's happening somewhere

and it's not being cached or we like
just don't You can see that pagination

or, you know, there's just like
little, little things here and there.

Like we show a badge in one of the
navigation menus that tells you

how many unread messages you have.

And we just like re query every
time you load the page for.

Like show me all the messages you
have read and then give me the

Delta between that and like how
many other messages there are.

And so yeah, like low hanging
fruit stuff where we need to add

like a little Redis caching layer.

But other than that, it's been super fun.

We've been using hotwire and turbo a
ton and it has worked surprisingly well.

So.

We just added a, there was
a request for a feature.

So we have a command palette
thing using ninja keys.

I don't know if you've seen that,
but yeah, senior like similar to in

linear where you can do like command
K or you can use the slash key to

pop open a little command palette.

We have a command palette for jumping
around and there was a request to like

add a feature where in the command palette
you could see recently viewed projects.

And I was like, at the same time
I was thinking it would be nice to

have the experience that you have in
Google docs, where you have like, you

know, everyone's face who's viewing
the doc right now in the top, right.

And it was pretty fast to get up and
running with action cable and just showing

who's there real time and then collecting
up all those project views into some

models and then spitting that out as
like you know, recently viewed projects.

So we have kind of like a
LRU cache type situation for.

The command palette.

So you can quickly bring
up recently viewed.

Pages and you can also see who's on
the page that you're viewing and yeah,

I've been really pleased with that.

I think we have followed convention,
it's really benefited us.

So yeah, I wrote a blog post that we
can leave a link to with just like some

reflections on the last year and also
just like things like rules of thumb that

we've sort of picked up for rails over the
years that folks might be interested in.

I think in particular, I've gotten
very opinionated about enums and

like not to use them certain ways.

So if you're curious, like
I don't reject that up,

Colin: That's, that's a good one.

I'll have to read it because
we have the similar things.

We've, I've come, there's like the
rails, there's a lot of different

opinions about that in rails.

And then I've now learned a lot about this
in terms of we use a lot of like integer.

Enums.

And the nice thing is you don't
end up having to rename them later.

Like when you're like, we're
going to reuse this or change it.

You don't end up with like
install v2 final final.

Right.

So you'd be like, well, now zero
is this instead, or one is this,

but yeah, it can be enums or
there's a lot of foot guns there.

CJ: Totally.

Yes.

Yeah, I think there was, there was,
there was a video that I made on

YouTube and someone in the comments
was like, why don't you just like,

it's a best practice to always have
like store integer values for enums.

And so I just like trusted this
random person who left a comment and

I was like, Oh, that's good feedback.

I'm going to use that now that someone on
the internet said it was a best practice.

And I like, didn't really like look
into it, but I was just like, Yeah.

I internalized it.

I was like, okay, well maybe
this person must've been right.

And like, surely for performance,
it's better to store them as

integer values instead of the
string values in the database.

But the reality is like, as soon as
we had downstream services hooked up

directly to Postgres for our like business
intelligence tools, now like everyone

needs access to your Ruby model, like
your actual like Ruby code to know like

Colin: Yeah.

What is one, what is

CJ: is.

Yeah, exactly.

And so now we have these like giant
select case statements in all these

third parties and anytime an enum
value changes, now you have to go

update it in the third party too.

So

Colin: like you have to have a
response model or something in an

API to make sure that you translate
the enums to a nice string value.

Or you, I guess you could return
the integer, but now you're telling

developers into like either create
a library that then translates those

into whatever those values are.

Yeah.

CJ: there was, there was other, like the
other story that I might tell is that like

we started out with what I thought was
going to be a small set of enum values.

And over time it was, it was
to represent types of services

that we provide basically.

And it was like, Oh, we're
going to paint the walls.

You can paint the ceiling, paint trim.

And over time the team wanted
to like adjust and shift with

those meant and add more.

And so as we started adding more
union values, we got to like,

Over 25 or 26 or something.

And then we started to like encode
things into the string value.

That was like, Oh, paint
underscore square foot, underscore

brick, underscore sighting.

And that meant that it was a paint
thing that we're going to do.

And it was square foot based.

And it was this other thing.

It's like, Oh, actually like the
enum key in this case is encoding

like a bunch of data that should
be probably in its own model.

And would be much easier to work with.

So yeah, lots, lots and
lots of learnings there.

Colin: Very cool.

CJ: Yeah.

What else

Colin: got some sidekick stuff going on.

CJ: Yeah.

So in the past, I don't know if
you remember, there's like a Heroku

add on called Heroku scheduler.

Yeah, I used to use
this thing all the time.

This was like my go to way to like set
up any like periodic background job.

Meaning, yeah, it's, A lot of times
we'll build background jobs that just do

some processing in the background based
on a trigger, meaning a request came in

through a controller and then you kick
off a background job, or a webhook came

in and you kick off a background job.

But there are things that you want to do
like every day at four o'clock, or you

want to do it, you know every Friday at
six or something, or maybe you want to

do something every minute so you can go
through and check your database to see

if you need to do any, you want to do.

Sort of data sanitization or whatever.

So all of these periodic task type things,
I used to solve them by writing rake

tasks that would kick off background jobs.

And then Heroku scheduler was this plugin
by Heroku that lets you set a cron style.

Thing that would kick off your rake task
on a schedule and there was like a little

ui that you could use but now that we're
on render we didn't have access to that

plugin And so I started looking into
these a couple of different alternatives.

So whenever the whenever gem was one
that was part of jumpstart already,

but I liked sidekick cron for a couple
reasons one it because we're already

using sidekick You And sidekick web, it
adds like another tab to sidekick web

where you can click on the cron tab and
you can see here's all the jobs and when

they're scheduled, when they ran last.

And you can even like, Enable and
disable them from the UI and you

can kick them off from the UI.

So I really liked the
way that that fit in.

And so set that up on my personal side,
just to like experiment a little bit

with fetching these podcast episodes
so that it updates on on the website.

And then also I set it up in buckets,
our little finance app that we've

got going on to just start fetching
some data that's not coming in via

webhook for a couple different things.

So property price values from some
property APIs and yeah, I think it's,

it's, it's been serving us really well.

So we started using it internally to send
push notifications to our mobile app.

At the end of every day to like remind
people, Hey it doesn't look like we've

seen a progress report from project X and
it looks like you clocked in there today.

Like, can you send a, send an update?

So,

Colin: Nice.

Yeah, we made, we made heavy use of that
at the subscription underwear company.

Right.

We had a lot of Heroku scheduler going
on for subscriptions or like it's

time to run everyone's subscription.

Cause the way Shopify worked, we had Tell
Shopify when to run the subscriptions.

It was kind of maddening.

Even though I think it was using Stripe
under the hood, which is another story

for another day, but and then at orbit,
we use sidekick cron with sidekick, like.

We were constantly looking at that screen
and just seeing like, literally like

the one that was always backed up was
like integrating with discord because

the right limits, it was always like,
okay, how many sync jobs are running?

But it was super nice to be able to
say, run this every hour, run this

every day at four, run this whenever.

And we would usually schedule them.

I guess that's probably where they,
they came up with the name for the gym.

But we would often schedule around.

Like we, we had built a.

An HTTP client that also was
aware of the queuing and the cron

so that it would stay within the
rate limits and like respect it.

And then like delay job if we
were going to hit the limits or,

you know, whatever was going on.

So I find myself missing some of
those tools in JavaScript land.

I know you could just write your
own scripts in JavaScript, but

like the idea of like, these are
rake tasks that then create jobs.

That then have workers
that run in those jobs.

And it's like in JavaScript, you have
to kind of just go do all of that.

I just found a bowl MQ that
I'm looking at for some stuff.

There's a few blog posts that I found
where like top five message queues and.

Background processors to use.

Cause I'm working on kind of
like a best practice for billing

in a bot or an app on discord.

So like kind of what are all the events
you need to listen to and don't do

it in band and store it in a job and
then process it and stuff like that.

So I was like, okay, I normally reach for.

Sidekick.

And I was like, okay,
we're in JavaScript land.

I'm sure there's probably a way to
do sidekick with JavaScript, but

it's probably not designed for that.

CJ: Yeah, I have no idea.

I have not seen that.

I haven't seen Sidekick used with
JavaScript, but when we were when

we were first building with Next.

js, we used this tool called Ingest
with, it's like n with two n's.

And at the time, I, I thought it was
pretty, it was a pretty new company.

And this is like their, their entire
company is built around like being

a service that provides background
job handling there were a couple of

things I really liked from ingest.

One was the logging and like just
keeping track of when your jobs ran.

And then they also had some like.

Interesting concepts around, I think
it was around like trees of jobs that

could have interdependencies and things
like that, which can get kind of messy.

But yeah, it worked great for
us for a while and we used it

to send emails and handle a few
things before we set up rails.

So but I, yeah, I remember looking
at bull And a couple others that

were just like, how do you host this?

Where do you run it?

Like, what is the worker?

Like if I, if I deploy my next JS app
on Vercel, like is my bowl MQ thing

happening on Vercel or somewhere else?

And then it was like, do you just set
up a serverless function that runs your

background job as a separate thing?

And then like in your main job, you're
like to schedule your background job.

You just hit the serverless function.

And then, yeah, I don't know.

There was, I remember it being one
of the many frustrating things in

JavaScript land being that like every
single piece of the puzzle is like,

where do I get the third party SAS
product that solves this problem?

So,

Colin: Well, and it's tricky
when you start looking at the

renders and flies and stuff.

It's like, if you're running in this
like quick to deploy thing, like it's

like, it's like why Heroku had an add on
store and why they had Heroku scheduler.

And I'm sure Chrome, like they have
probably some features, but when

you just hit a key, like a worker,
you loo there's so many things

like, do we have observability?

What happens if it fails?

What happens if it needs
to call some other ones?

And there's like a fan out and
there's all these different things

that you have to think about.

So like, yeah, looking at Ingest's
website, it looks like they've maybe

started leaning towards AI jobs as
a service, but still, still a worker

system, but very heavily on that.

LLM chain and like, usually
you're doing lots of requests.

It's like chatbots and things like that.

But, you know, it looks like flow control,
logging, observability, recovery tools.

You're doing all that yourself if you
don't use a tool or like, I think some

of it, what's nice about Sidekiq is
there's so many plugins to Sidekiq.

There's like retries and there's
back like exponential back off and

you can define all of that stuff.

We used to use a company that is no longer
around called iron worker or iron or iron.

io.

That was very similar to, this is like
over a decade ago, but very much like,

I do not want to think about where these
jobs are, where they work and you can

deploy go and Ruby and all these different
ones to them and let them do that, but

that's like a whole, it's a whole world.

Mm hmm.

CJ: Yeah.

Yeah.

I think in Django we use DJ celery or like
a J or some, some sort of celery thing.

And I remember George had to go like
super deep on debugging some lock issues

where like we were, we were writing to.

Some cue and celery had to
pull stuff off the queue.

It's like not simple to get right.

And so, yeah, I do appreciate that
sidekick is backed by a actual business.

And it seems to have lots of great
support with different plugins and

features and oftentimes the stuff
too, that comes with the paid.

Plans for sidekick other than support,
obviously, but a lot of the features

that you can get from Paid are also
available as community packages or

a lot of it is just ruby So you can
kind of treat it as a ruby object

and go into it and write your own.

I think we built A debounce like
our own like debouncing thing.

So if you kick off several different
jobs that all have the same arguments

to perform and they're all item potent,
then it'll debounce them until you

stop creating jobs for like a minute
and then it'll run the last one.

So yeah.

Great little tool.

Colin: Very cool.

Yeah, on my side, I've mostly,
like, been working on those

bots, like I was talking about.

Mostly just carving out some best
practices, figuring out what our docs are

missing, figuring out what things, like,
kind of cursive knowledge that we have.

Like, what are we missing?

What are we doing?

Discord is interesting that we don't have
our own SDKs, so we, like, I'm writing

everything using just, you know, Pure API
calls right now, but we'll probably also

do it in a few different libraries just
to, so that people have some examples,

the libraries have pretty good support and
guides and stuff like that, but there's

some things where like the libraries
don't always implement all the things

that we offer, so just trying to show
off, like, what is our interpretation?

Maybe what we recommend is not even
necessarily how it's written in the docs.

And so when you do.

Get that back in line.

When things just change
and need some updating.

CJ: So when you're working on a sample
bot in JavaScript, are you're using

like a third party, like community
JavaScript library, or are you

writing like just fetch calls or how's

Colin: Yeah.

Like I'm usually using like Axios or
something just to have a nicer little

rests and point or fetch if I want to just
have something without any dependencies.

Mostly just because then the reference
implementation is without any specific

library so that library devs can see it,
developers can see it, and then that way

if you're building something and you're
doing it in another language that's not

JavaScript, you can just see what the
control flow is on the JavaScript side.

Are we going to end up with like
examples in a bunch of other languages?

Maybe, I think like most of our bots
are probably JavaScript and Python.

So those are like the two big languages.

Discord, RB is really
cool as like a Ruby one.

We use that at at orbit.

And yeah, there's, I mean, there's
10, there's dozens of of SDKs.

So like there's someone who has one in
R and in Crystal and in Ruby and Elixir.

And so it's,

CJ: do you get telemetry on like
which ones are most popular or

is it kind of like anecdotal?

Like,

Colin: Yeah, they're supposed
to send like a user agent.

So we have a good sense of like
what the top libraries are.

And a lot of the really large bots
have their own clients and, or forks of

popular clients just because when you
get to large bots, Really large bots.

They have to deal with the gateway and
sharding and like limits on the gateway of

how many like if you are running multiple
instances of your bot connecting to

pools of guilds and servers, like there's
a lot of overhead where a lot of our

examples are for bots that we just assume
you're not going to get to that issue.

And like our newer bots mostly use
HTTP and there you're getting like

webhooks instead of having to do
an open web socket to the gateway.

So there's a little bit
of a movement that way.

We don't support webhooks for
everything that the gateway has.

It's only for very specific, like
the slash commands in discord

are powered by webhooks usually.

Or you can do them via the gateway too.

So some of this is like, okay.

Now that we have this, like,
should we be offering more events?

Should we be moving to an HTTP future?

And, and cause the nice thing
about that is you don't have to

do sharding and you could have one
instance of your bot running that.

Takes those and puts them
into a job queue, for example,

CJ: and it, are these examples all hosted
on GitHub somewhere that we could check

Colin: They will be, yeah,
there'll be in the docs.

So I'm working on like a refresh of a
lot of our docs content, just trying

to get rid of some of the older stuff.

We've got a lot of things that
are like, this is deprecated.

So it's like, okay, we might just
say it's been deprecated for a while.

We're going to shove it into get hub.

Here's the get commit if you
want to go read it again, but.

We're going to get it out of the docs.

So yeah, there'll be in the docs, discord.

dev.

CJ: Very cool.

And are there, when you're talking
about like building apps around best

practices, like how are you, like,
how do you go about figuring out what

patterns people should implement?

Are you looking at like, ways that the
bigger bots have done it or talking

to like the engineers internally or,
yeah, like kind of what's your approach

to figuring out the, the right or
the way that you want to recommend?

Colin: this is kind of like a
side quest for me that I haven't

really told anyone that I'm doing.

So what I'm doing is my interpretation
of what I would do if I was an

external developer, because that's
the failure point is like, what are

we telling people to do, and then
I'm going to take it to the team

and say, okay, I implemented this.

Please poke holes in it.

Like we'll do like a demo day type thing.

What would you do differently?

What are the concerns that I'm
not, what are we, what are we blind

to that we aren't telling people?

What am I, what did I also do
that wasn't in the docs because I

know that I have to do this thing.

So that's a note for
me to update the docs.

I think for a lot of developers,
like they want to see code and they

don't want to just read because
they're not going to read usually.

We hope that they read, but the code
can be very self documenting that way.

And then we can also take PRs
if the community thinks that

something could be better.

What I'm trying to figure out
is like, The discussion we just

had about workers and stuff is
that's when you get into opinions.

It's when you get into tech stacks, right?

Like when I start thinking about
like, here's where we should implement

a caching strategy, we could just
say, choose a strategy of your.

Your own and just not show an example,
or we could do what I'm trying to

figure out is like the same app.

Do I do it multiple times?

One super naive in band requests.

You can run it and it's going to run fine.

No dependencies.

The next one's like, okay,
this is using bull MQ.

And here's how you would save these two.

Job queue, process them,
and why you would do that.

But then, of course, you get the why
aren't you using my favorite queue system.

And then the other one would be like,
okay, here's another one using Redis

as like a cache, and here's how we
recommend, you know, doing your cache

and validation and stuff like that.

Those are not things that we document.

Like, it's not our job necessarily to
document how to do caching as a job.

Concept, but I think if we expect you
to have a good time that you should

be caching or we should be offloading
those things, then I think we should

tell people that because otherwise
you're going to hit rate limits, then

everyone's going to go ask, like,
why am I hitting these rate limits?

And so there is a little bit
of that, that I think we can do

to make people more successful.

And then we run into the, okay,
now I want this in my language.

Now I want this in.

You know, some flavor of a library
because a lot like most people are not

going to do raw HTTP requests either.

So like, what is the Discord.

js example of this?

But my hope is that if we
offer these that then Discord.

js can translate that
into their own version.

Or they can tell us like, Hey, we don't
think that that's the best way to do this.

Some of the SDKs, they're really, they're
like more like thick clients than thin

clients that they do a lot of the caching
for you or like the discord RB one it has.

A really cool way of keeping
you within the rate limits.

And so like, it's aware of how
much you've used what's available.

It will intentionally delay your requests
and things to make you fit within that.

So it's still possible to hit it.

Like if you do something, you
can slam into it really hard.

But there's some of that stuff that's
like not going to be captured in like

a generated open API SDK, for example.

CJ: Mm hmm.

Mm hmm.

Yeah.

One thing that came to mind while you
were explaining that was the, there

was like a period at, at the end of my
time at Stripe where I wanted to give

people my opinionated implementation
of how I would do something with Rails.

For a Stripe connect integration.

And I wanted to show like, here's
how you should handle your web hooks.

And here's how you should like
farm stuff off to the background.

And here's how you should do X, Y, and Z.

And it really, we had a hard time
like finding anywhere that it might

fit in the docs, in the proper docs.

Cause in the docs, it's like, you just
want to tell people the high level stuff

that they care about from that's like
tech stack, agnostic, whatever from

Stripe And it was yeah, so it was like
this, we got into this situation where

it made more sense to write them as
blog posts that were just posted on dev.

to or my own, like my own website
or whatever, because it's like,

it's actually just my opinions,
but about how I would do it.

And with those like additional
things like sprinkled in.

So where in the docs you might say
like, yeah, we recommend using a caching

strategy here in like the blog posts.

It's like, okay, here's how
I did it with caching in this

specific stack or whatever.

But yeah, I think I,
I did a bad job about.

Like doing a lot of collaborations with
other dev rel teams, but there were

other people on, on our team that were
good at saying like, Oh, Hey, we might

want to do a caching strategy here.

Let's do like a partner video
with some other, like some company

that's like a caching company.

And so then it's like, okay,
here's how you could use ingest

in the context of a discord bot.

That's like sending the thing.

And then you kind of like work together
to make a live stream or you work

together to make a blog post or whatever.

Yeah.

I don't know.

Kind of,

Colin: Yeah, that's a good

CJ: it's tough to get

Colin: a good call out because I haven't
gotten that far yet But this will

probably be like like a dev 2 article
or it could be you know Let's go do it

live on Twitch or a discord dev YouTube
channel, which we do not have right

now, but we might one day Those kinds
of things so we'll think about that.

But yeah, the the tricky thing about
partnering Is we found this even

with open source implementations
of like a certain job queue is

then like our docs are public.

So if we implement one, we're going to
get PRS for everyone's favorite, whether

it's their proponent of that one or
their DevRel for that one, or they want

GitHub contributions to the discord repo.

So, you know, we get all of them.

We, cause we did that for activities.

We, we picked a third party.

Multiplayer backend.

And the cool thing is that company
has that since built their own discord

example, that's way better than ours
because like it's from them, they

understand their tool better than we do.

So we were probably going
to swap that out for theirs.

Cause a lot of people were
like, why did you pick that one?

And you know, why aren't
using mine or this paid one?

It's like, well, it was open source and
our team clearly had used it before.

So it was more of like, we want
to give you an example instead

of make you do it yourself.

But, you know, some of those opinions,
I think what I would like is that

the docs should at least make you
think about like that, like that you

should think of a caching strategy.

And then maybe that's a, Maybe it doesn't
make sense to do a call out to like

implementation there, but if it feels
more human, like you can have the super

technical docs with a fun little bubble.

That's like, we recommend a caching
strategy, go check out how CJ

did this and rails or whatever.

CJ: Mm

Colin: you can kind of cross
promote, which would be fun because

I think like at the end of the
day, like especially with discord.

Like we should have some fun with it.

It doesn't need to be this like cut
and dry, like you know, manufacturing

guidelines for implementing XYZ.

It's like it's discord.

CJ: Yeah.

Speaking of fun, I, the little
touches that have been popping up in

D script lately have been pretty cool.

Like,

Colin: The name of the AI
assistant was a strong choice.

I don't know any context about
why it's called Underlord.

Is that what it is?

CJ: Yeah.

Under the under Lord, you go
to the under Lord to have it

automatically do stuff for you.

Colin: Well, in a world where, like,
almost every AI assistant seems to

be named, like, a woman's name, which
is, like, problematic all to itself.

Right?

And, like, or they're trying to
make them human feeling, and now

you've got, like, the Underlord, and

CJ: Yeah,

Colin: I wish I was in that,
that marketing meeting.

'cause naming things is
always hard, but also so fun

CJ: I know.

I'm sure someone was just like, what
if we called it like the overlord?

And they're like, no,
no, no, no, not overlord.

That sounds scary.

And they're like, under Lord, like sold.

We'll call it

Colin: But then, you know, that
whiteboard also had like, what

if we called it Dan or DS Script?

Dan

CJ: Yeah.

Yeah.

Or like the Descript dog.

Oh, like, you know, like a lot of
people want to have a, a mascot.

Situation,

Colin: for sure.

Well, we'll be using under
Lord to edit this episode.

So

CJ: yeah.

Brought to you by the Underlord.

Oh gosh.

All right.

Why don't we wrap it

Colin: right.

Good chatting.

Where can we find all the
notes and all the things?

CJ: Yeah.

Head over to build and learn.

dev for links to all the resources
to the stuff we talked about today

and yeah, we'll catch you next

Colin: All right, bye friends.

CJ: Bye friends.