APIs, Acquisitions, and Event Emitters

This week, we discuss building companies on top of API integrations and recent acquisitions that we've been following closely and dig into some tech we're both using in our daily work. If you feel like you have a lot going on in your world right now, we also tease our upcoming episode on Cal Newport's newest book, Slow Productivity.

- Postman acquires Orbit! Congrats to the team!
- Discussing building companies that are heavy on integrations
- Autocode shut down
- Cloudflare acquires Partykit
- Using Turbo at Craft
- Calendaring and staffing in Craft
- Neverending conference room app
- Slow Productivity by Cal Newport
- Podcast Interview with Cal Newport
- Cal Newport's website
- Events and Event Emitting
- Building and learning on Game Engines

Creators & Guests

Host

CJ Avilla

Developer Advocate @StripeDev. Veteran. 📽 https://t.co/2UI0oEAnFK. Building with Ruby, Rails, JavaScript

Host

Colin Loretz

I like to build software and communities. Building software at @orbitmodel 🪐 Coworking at @renocollective 🎙Sharing software learnings on @buildandlearn_

What is Build and Learn?

A podcast about software development and developing ourselves as software engineers. Hosted by CJ Avilla and Colin Loretz.

CJ: What's up, Colin?

How's it going?

What's

Colin: Hey, how's it going, CJ?

We are back.

Build and learn.

How's your week looking?

CJ: Pretty good.

It looks like you dropped in a
link to an exciting announcement.

What's what's the deal?

Colin: it looks like you're
wearing a celebration t shirt, but

CJ: Yes.

Colin: CJ is wearing his postman
shirt today probably from some sort

of DevRel collaboration or events.

But my former startup Orbit appears
to have been acquired by postman.

So congrats to the team over there.

And it sounds like they're going
to be working on the Postman API

network kind of more shifting gears
towards Postman's developer community

of APIs and things like that.

But long time coming.

So kudos to the team and Josh and
Patrick for leading that effort.

CJ: Yeah, it's it's been an interesting
couple of years for Orbit, for sure.

And yeah, it's good to see that
everyone landed at a pretty cool spot.

I, I like Postman a lot.

I've been using it way more recently.

And yeah, I think I have been surprised at
how much it's increased my productivity.

And I think like a big part of it is just
like, staying organized with collections

for all the different API integrations.

And then under that, like having
folders that automatically sync and

then having different environments.

So you got like your production
environment, your local environment and

variables and writing, like, I don't
actually use the tests feature of postman

for for testing, but I use it for like
saving and writing variables that were

the result of like a previous request.

So you can say like, yeah, with
Twilio, maybe you make an API call.

That creates a conversation and in
that response, Jason, you want to save

off the conversation ID in a variable,
like a postman variable that you can

then use in other requests later.

So yeah, I've been, I've been loving it.

I think for a while I jumped between
insomnia and a couple other different

rest clients, but have you, yeah, have
you been a postman postman user for

Colin: I've, I've,

had an account for a long time.

I've been using it more because we
have the API spec from discord that's

feeding into the collection there.

And I'm going to actually be at
post con at the end of this month.

So.

Probably right when
this episode comes out.

So if you're going to be at post con
come find me, but yeah, we'll just be

geeking out on API as I imagined at
post con and learning more about, you

know, best practices around APIs, but
we've been, I think we have like 1.

7 I guess, 1700.

People who are subscribed to
updates to the API through Postman.

That's kind of another feature as, as,
as we update the spec, it updates the

collection, and if you're subscribed to
changes and you can see that downstream

and we, we aren't using any of the
test suite things or like the runners.

I've been really curious to
check out the runner feature and

just see what else we can do.

We have a bunch of different.

Auth tokens and we need to
document those better in there.

And sometimes specs are like the technical
thing, but not the how to use this thing.

So we're trying to just figure out
how best to show that, make that

show up in postman so that you
know what goes where and how to

go get it and all of that stuff.

So.

Yeah, pretty cool.

I use I use paw, which is, I guess now
also was acquired, I guess a few years

ago, but it's the rapid API client
locally, but I only use it for myself.

And I think the benefit of postman
is that like figma style multiplayer

of like, you know, back when I
think figma has won the game on most

things because it's multiplayer.

What was the other one that was
really popular before figma sketch.

Yeah.

And You know, Figma kind of ate
their lunch because it just wasn't

as multiplayer, and I'm sure Sketch
is today, but Postman's got that,

that it's great for teams, so
having workspaces and all of that.

CJ: Yeah.

Did I read correctly that
orbit is basically going to

shut down like the existing.

Colin: It looks

like

CJ: yeah, orbit's closing down.

They're pivoting, but I think
like there's, there's pretty good

alignment between the audience
that orbit was going after and the

audience that postman is serving.

And so like basically just continuing
to grow developer communities, making it

easier for people to connect with other.

Yeah.

Folks that are using your API,

Colin: Yeah, and I

CJ: to make a lot of,

Colin: I just have what's in
Patrick's announcement email here.

So I don't know anything beyond
the, the blog posts that are public,

but yeah, the Orbit team will be
working on the Postman API network.

If you're using Orbit, Orbit users
have 90 days to wind down export

their data, so no more new data.

There won't be new data
ingested and things like that.

So, which there's a lot, there's
a lot of data flown through.

I think we talked about it on the show.

Some of the things that that I spoke
on at RailsConf around that whole

network integration suite of how we
would integrate data and pull that in.

I imagine they'll
probably use some of that.

We'll see.

It's pretty cool.

CJ: it, it also like just taking a step
back and looking at this acquisition,

it's another data point that building
a company around like lots of API

integrations still does not seem to.

Work like perfectly right.

Like which is disappointing.

Cause that's like the favorite
kind of thing that I like to build.

So I don't know.

It's what, do you have a sense of like
the trend there or the pattern there,

or like things that people ought to
look out for if they want to go down

the road of numerous or, you know,
building an API integration company,

Colin: Yeah.

I think, I think like you and I have more
experience than that, than the normal

engineer, I think, or not the normal
engineer, but the, you know, the average

engineer has probably dealt with some
APIs, but you and I have had to integrate

with dozens and dozens in one app.

Right.

Okay.

What I like about the acquisition is
that it's proving and showing that there

are startups still being acquired by the
companies that are not the Microsoft's

Googles, but that tier below that Postman
has a great user base, great community.

They have the ability to buy companies.

So things like that are great.

Cloudflare has been buying a bunch
of companies, things like that.

So it makes for a healthy ecosystem.

If people are still wanting to start
something, I think, which is great.

You're right.

In that if you focus on the integrations,
you can spend all your time there.

and lose sight of the problem
that you were trying to solve for

the customer in the first place.

And there's this long tail of integrations
that like, is the, the nth next

integration really going to add product
market fit, or do you need to solve the

problem for people who use one or two
of those integrations and just say like,

yeah, we are the best tool for this.

And I've thought about that.

Like if I ever did build
co working software.

I would say it's the best co working
software for Stripe users, period.

Like, I would not want to touch
PayPal or any of the other

hundred payment providers.

And people will probably then give
you reviews of like, oh, they don't

support X, so I'm not going to do it.

And it's like, yeah, but it's just
a really, really long bridge to

nowhere when you're integrating
every single thing under the sun.

Because then you got to support
them all, maintain them all,

answer questions on all of them.

You got to learn them all really well.

CJ: Mm hmm.

Colin: that's kind of where
I'm thinking about it.

I still love integrations and APIs
and all of that, but I do think

quality over quantity is probably
the winning formula going forward.

CJ: Mm hmm.

Yeah.

It also seems like at some point,
Orbit was encouraging people to

build their own integrations, right?

And just like use the Orbit API,
but build your own integration.

I am struck by the fact
that like Zapier, Make.

com you know, if this than that, like
these types of companies where it is

purely like the integration platform
that those they're able to be successful.

And I wonder if it's because they've
reached some sort of critical mass

where they have enough integrations
where they can get people to use it.

And then by people using
it, that encourages third

parties to build their own.

Apps like on top of it.

And that just like creates a network
effect that continues to drive more

integrations from third parties.

I don't know.

Like, how do you, yeah, basically,
how do you reach that that critical

Colin: Yeah.

CJ: to get people to use

Colin: Well, and with Zapier,
like the Orbit Zap, we had to

maintain it, not, but right.

So like.

They don't have to learn if someone
wants it, someone's going to

build it and it doesn't have to
be that company that builds it.

Sometimes, sometimes it
can be a third party dev.

You're right.

Make a lot of this is like user generated
or third party supported integrations,

which come with their own issues.

Right, like if you release a new feature
and then it's not in the third party

thing then that can be harder and you
can't go make a third party go add a new

feature or something Or maybe they don't
implement it the way you want them to

or how you would do it make is a good
example There is another announcement

that i'll share in in the show notes too,
which is that auto code is shutting down

and They are one of these similar tools,
like API integrate with all the things,

but it was also like kind of replete.

Like you could write code in the browser
and do chat bots and things like that.

And when you dig into it, it
was run by a very small team.

I know about them because of discord.

There's a lot of discord bots or
rather a lot of people learned how

to build discord bots using this.

And they even talked about
this on Twitter at auto code.

A lot of people learned to use the
APIs and build bots here, but then they

went, they graduated off of auto code.

Like as soon as they were, they learned
it, they would go spin up their own

Heroku or their own box somewhere, and
then they would have their own app.

And the person who ran this.

is going over to OpenAI because
there were a lot of GPT bots

that were built with this.

So, as far as I can see from the
announcement, AutoCode is going to get

shut down but they have this really
cool project that's called Instant.

dev that they run, so I'm curious
to see It's an open source thing.

They basically have said, like, if you
want to take your auto code projects,

you can spin them up with instant.

dev on CloudFlare or wherever
you really want to host it.

I don't know if it actually is CloudFlare.

There's like a bunch of acquisitions
that I'm now kind of getting crossed

in my head because the other one
that I'm kind of excited about,

this is just the acquisition show.

Is partykit.

io is being acquired by CloudFlare.

And this is like a really cool
way of adding multiplayer and

collaboration, like, like y.

js auto merging of documents and
things like Google Docs style.

And if you go to partykit.

io right now, CJ, you see my
cursor and I see your cursor.

So this powers that like
Figma style multi thing.

And I think if you hit slash,
it doesn't work on the website.

Okay.

But they had the ability to type and
then the, the typing would happen.

And even in that background you
can see that the, the background

is changing based on your cursor.

So, this like multiplayer
state is handled by PartyKit.

And so, they just got
acquired by Cloudflare.

So like, there's a theme here of APIs.

State.

multiplayer.

So if you're building something out there,
think about, you know, how you can build

that like network that you plug into all
these other things, because maybe one

day when you do want to get acquired,
you now have this like rich relationship

with a bunch of companies that will be
like, Hey, like half of our, half of our

users are coming from your tutorials.

Maybe we should just buy you.

CJ: Interesting.

Yeah, I have, I've been really
impressed with how well Repl.

it has been able to, like, go from
kind of a toy browser thing where you

can write a little bit of code and run
it To like now they're pretty legit

like hosting company that starts with
browser, like a browser editor that

is multiplayer and collaborative.

And yeah, I, they've been doing
a really, really good job.

I think of just continuing to build
insanely fast and releasing features

and like really, really fast.

Especially for like younger and
newer junior devs, apparently like

a lot of Audiences, folks who are
graduating from like scratch and they

want to run something and they don't
want to set up their environment.

And so they just throw it up
on replit and off to the races.

So yeah, interesting to hear that.

Autocode is shutting down
this party kit thing.

I think I heard about this on a
syntax FM episode, but I never

went and played around with it.

It looks really

Colin: think I first found it as a
way of adding a Stripe like customer

satisfaction type thing to the bottom
of every docs page where you could

technically do it with like a key value
stored anywhere, but you still need that.

Like you click the thing and then
it updates the counter and it would

actually update across to everyone
who was on the docs at the same time.

And kind of like giving an
Instagram post, like a heart.

Right, you can add that interaction and
the cool thing is if you're on the docks

when someone likes it, you see the little
animation pop up and just a little bit

of surprise and delight, but also just
like, if you're reading a thing and you're

like, Oh, I'm getting a lot of value
out of this and then you see all these

hearts pop like popping up, you might
also be inclined to click it as well.

CJ: Yeah.

This is all stuff too,
that you can achieve with,

uh,

Colin: Tell us more.

CJ: and rails.

Yeah.

Like we've been learning
a ton about turbo.

At craftwork and most of the team
comes from a react background.

And so they want to make the
application like they have a lot

of expectations around how the
application can be built in a very

front end, like single page appy way.

And so there's features that
we're adding that really.

Would typically lend themselves
more to a react based application.

But we have made it really, really
far with just hot wire and turbo

streams and things like that.

And so we have a lot of.

A lot of pieces of the application now
that will make a request as a turbo

stream to the server, the turbo stream
web components come back to the client,

and then we'll update or replace or move
certain things on the page instead of

reloading the entire page and an example
of that is as part of our messaging

feature, if we receive a message from
a customer, It will go and like live

up, like live broadcast and update
notification counters and things like

that on anyone who's currently active.

So yeah, like everything that you
kind of like know and love from a

Slack application or discord, right.

Marking something as unread and
telling you that it's unread through

these turbo streams is pretty.

Pretty sweet.

Colin: Across multiple clients.

If you're on, if you have a
desktop app, does Kraftwerk have

or plan to have a desktop type?

Or

sorry,

CJ: We call it crap.

We're

Colin: or I guess mobile rather.

CJ: yeah, we do have, so we have
a react native app that is mobile,

but we don't have any web sockets
integrations yet with that.

So it's, it's on our mind and
we've got sort of the the cable.

Action cable stuff working so we
can broadcast Jason when things

are updating and then use that.

You can kind of like listen on any
device for those broadcasts or any

device that can run JavaScript.

You can listen for those broadcasts
on certain channels and then

update the UI based on those.

So yeah, we've got a few little
hooks in place, but yeah, party

kit maybe we need to build like.

The turbo party kit.

There's probably something like that.

All right.

I bet.

Colin: I think the, the advantage
of party kit for like a static site

generated site is there was no backend.

Right.

And so party kit is the backend.

You are building your backend.

And so I think you already
have what you need.

There might be some patterns and some
cool, like if you look at their examples,

you can be like, how would we build this?

In rails with turbo, and I think that
would be the equivalent, but you know,

with a lot of people doing thing and
on all these like static deployed

sites and cloudflare and all that,
oftentimes you don't want to, you

know, mind doing some of this stuff.

I think they're more intense stuff was the
YJS, the like, we're going to both edit

the same sentence and there's going to be
a merge and a diff and who's going to win.

Yeah.

Those kinds of things are painful to do.

So sometimes it's nice to just let
Yjs or PartyKit or the integration

between both handle that.

So,

CJ: Got it.

Okay.

This makes a lot of sense.

Colin: I could also be getting some
of this wrong, but that's, that's

my interpretation of PartyKit.

CJ: okay.

Yeah.

It seems like you do have
to have like for Yjs.

It's expecting that you have some server.

So maybe there's like a, a rails
version where you implement the,

Colin: and then you have a Yjs front end.

You can build your own
Google sheets, Google docs.

CJ: Yes, which we've talked about, we've
rebuilt so many things at craftwork.

It's like, okay what, what's next?

What are we going to do next?

I think next is calendaring, which
is funny because I know you've got

some more updates about the calendar.

One, one thing before we move on from
party kit, I noticed that TL draw is

one of their kind of like Late, like
logos that they have is in terms of

like, who's using party kit and TL draw.

com is the site that had that
really epic demo where you can put

in your open AI key and then you
can just tell it like generate a

game that does blah, blah, blah.

And then it'll just spit out a drawing.

Colin: I see.

Yeah, I'm assuming I can share this
project and then I bet both of our

cursors would show up on TLDraw.

So, you know, most apps, we
kind of expect that these days.

Figma is, I don't know if Figma is the one
that really moved the needle on that, but

it's the one that comes to mind the most.

In terms of like everyone should just
be able to join and see things party kit

has a cool little demo that's just called
cursor party And that's the thing that

powers all the cursors on your screen
I'm working on bringing that into discord

just as an example app But it's unclear
like what's going to happen with party

kit as part of the acquisition So i'm
waiting to see where that lands first So,

CJ: Got it.

Got it.

Very cool.

Let's

Colin: What are you doing with calendars

CJ: yeah, so we're, we're just
now starting to figure out like

how to algorithmically schedule
crews and painters onto projects.

So as the crew continues to grow,
like, I don't know, I can't remember

how big, but let's just say.

Once we get to 50 plus painters it becomes
really challenging for a single person

to keep in their head, like who's out
sick, who's on PTO, who can hang drywall,

who can, you know, who, who knows how to
work the pressure washer, who knows how

to handle asbestos, et cetera, et cetera.

And then.

matching that up with projects.

So like maybe there's a project
we want to send the A team and we

want to make sure that they have
like an epic experience with a very

specific crew or painter or whatever.

So we're trying to build out like
these different features that you can

attach to a like a painter or in, Even
down to like leveling them, marking

up their skills, having a bio avatars,
like a bunch of statistics about them.

And then on the other side, like,
how do we figure out based on what

we know about a project, what are
going to be the skills that are

required to execute on this project?

Like from the estimate, can we tell.

This is going to need a pressure washer,
or this is going to need to have one

of those tools that like vacuum cleans
the popcorn ceilings off or something.

And then based on that, try to
algorithmically people to places.

So gnarly calendar problem.

But we'll see, it should be fun.

Colin: Nice.

CJ: What's going on with yeah, what's
going on with the conference room

booking stuff at the collective.

Colin: So I played around with trying to
build some of this with open AI and just

sitting down and just banging it out.

And it's just, it's doable.

The surface area is just immense.

Like all the edge cases.

And I don't want to solve for all
of them because it's just for us.

But then I have been tinkering, as
I mentioned, like, do I build this

so that I can just, like, put it out
there as a SaaS type thing that's

just, add your rooms, add your iPads
to each room, and it goes, and there's

no, it's not co working specific, you
could use it in a yoga studio, a gym.

I still, I think, want to do that because
there's just like so many fun things in

there, like, and like getting my hands on,
like, it would mostly run itself, I think.

I could drop the link in some co working
groups that I'm in that they're always

fighting over what software they use.

There's enough gyms and yoga
studios that I think would pick it

up organically, but Four days from
now is when ours stops working.

So it's like, I have a lot of things
going on and part of me is just wondering

if we just pull the trigger on paying
for it for another year, use it.

I just checked it ends up
being about 125 a month.

And that's where it's like,
it's, it's worth that obviously.

So we'll probably just do that
and it'll give us another year.

And I need to not wait until 11
months from now to revisit it.

Which I don't think I will, because
I have a pretty good start of it.

And it would just be like, it's
a React native app that runs a

React, checks the Google APIs.

And this is an example of, we
would only support the Google API.

Like I'm not doing this
for Microsoft calendars and

CJ: hmm.

Colin: else is out there.

No, I don't even know what
people are using anymore.

But Yeah, so I think
that's where we're at.

We'll probably just pull the trigger
on it, get it, get it set up again.

I mean, it's still set up, so
we'll just keep everything working

and then we can add people to it.

And yeah, they're, like I mentioned in
our previous episode, they're really

pushing this upsell of like having
people book desks before they come in.

And so it's really designed for
this hybrid work environment type

thing, which we're really not.

So like the first screen you
log into on the mobile app is

book your desk for the day.

We have to teach everybody, like
go down here to the calendar,

like the conference room page, and
then book your room and all that.

So we'll just do that.

I think that decision made commit to it.

And yeah, we'll see
how it goes from there.

We'll see if that whole like cow wind idea
from last episode becomes the thing and

bake it in there.

CJ: Yeah.

Are there pretty good
support for calendaring?

UI packages for react native on iPad.

Colin: So I was just looking at
turning all the calendars that

Tailwind UI has into actual, like,
they're beautiful, but they're static.

And so you need to go in and
create all the hooks for moving

events around on the screen.

For mobile, it would be more of a
different UI of like, just tell us what

day, we'll show you what's available.

So it will be a little bit different
on phones, but I think most people

would book through the website.

Maybe we make like a slack thing
that lets you just like slash book.

And we just launch us, launch a
temporary screen that you use.

And then it knows who you are based
on your slack and all of that.

But.

CJ: Cool.

That'd be awesome.

And I, yeah, there's, there's been a
few things where recently we're moving

off of services and that just creates
a lot of pressure to get something

completed and shipped and out the door.

We're shutting down.

One of our communication channels.

And so that was like, we have to have
like our new communication channel

set up and running and like tested
and everyone moved over by X day.

And it was a good forcing function.

It's like, okay, like we've
got to hurry up and like, make

sure this is live and working.

Colin: It makes

sense when it's your

CJ: can be stressful.

Colin: but for the co working
space It's like this needs to not

take up more of my mental space

CJ: Yes, absolutely.

Yep.

Yep.

Yep.

A hundred

Colin: Which leads into just more of
a recommendation and we can talk about

this more in depth in the future But
I was listening to a podcast where

Where the guest was Cal Newport of
like deep work and digital minimalism.

And they have a new book out
called slow productivity.

And this is for anyone who feels like
there's just a lot going on right now.

Like if you feel like your day is
dictated by Swiss cheese of meetings,

pings, slacks and discords and text
messages and social media a lot of

really refreshing takes and we'll, we'll
put a link to the podcast because it's

like a really fast introduction to it.

And more of an interview style.

And then if you're on Spotify premium,
it's free as an audio book there.

I've, I've started listening
to more books there and getting

rid of my audible subscription.

The subscription fatigue continues.

But trying to consolidate that and
the big, the kind of the overarching

theme is they actually are rooted
most of their stories and talking.

They're not talking to, but referring
to the stories of, of people who

have made these huge accomplishments
in their life, like Marie Curie

Jane Austen, Benjamin Franklin.

And it's like a lot of stuff's out there.

Like you should have the same
schedule as Ben Franklin.

And it's just like uber
productive schedule.

His is this, alternate take where if you
zoomed in on any one day of their lives,

you might catch them just at a park.

The next day, they're just on a
walk and they're thinking about and

observing and focusing on like this
problem that they've focused on for

years in their head, but they're taking
vacations and they're living life.

And then there's this intense
season where they publish, right?

Or they create this thing.

So like day to day, there's
not this hundred percent hustle

culture and productivity.

In fact, you have to take those
breaks to let things just run

in that background thread.

So really refreshing.

There's a lot of tactical things of like
you work for a company and you might

not be able to take off Fridays, but
here's how you can kind of simulate like,

like blocking, tackling your schedule.

If you can't use like the base camp
cycles thing of six weeks on and two

weeks off, he's like, you could probably
work hard for six weeks and then coast

for two weeks and people will remember
you for the six weeks and not the two

weeks where you were slacking off.

So a lot of really good tactical
things if you're looking for

like, okay, that sounds great.

How do I do this?

How do I take time off?

So it hit me right where I,
when I needed to hear it.

So I was like, okay, let's go binge this.

CJ: Yeah, I know you shared it.

I haven't listened to it yet, but
I, I really want to get into it.

Cause it also is like
perfect timing for me.

I was just telling Mike this week
that like, I owe everyone something

right now, like, you know, I, I've
like promised things to everyone

and it's a tough spot to be in.

So thankfully he jumped
in and helped a lot.

Colin: That's a big part of it, right?

Sometimes we, we, we care a little
too much and put it on ourselves.

And so yeah, let's both finish,
let's listen to that podcast

at least, and we can chat about
it more in depth in the future.

And honestly, I would not be
surprised if we could get Cal

Newport to come talk to us too.

So

CJ: Yeah.

Be great.

Colin: he's doing the book tour right now.

So

CJ: Yeah.

Deep work was huge.

So

Colin: you're struggling
with it, definitely check it,

out.

I think the other thing you
want to talk about, make it all.

CJ: Sure.

I mean, this is, this goes back to the
integration stuff a little bit, like make.

com similar to Zapier.

It's just like another version.

I was working with a client
who reached out for some.

Questions about a Stripe
integration they were building.

And they built like this really
sophisticated Stripe connect flow

in make like entirely with like no
code click and set up HTTP calls

and built like this giant series of
like 20 API calls to onboard like

an indie person onto their platform.

And so I was inspired to use it for some
nurture campaigns that we're going to do.

And We've been looking at it with the team
just to set up like some simple triggers

based on events that happen inside
of the Kraftwerk backend, basically.

And then some simple end points
where you can fetch information about

customers to know whether or not
you should we should message them.

And then you can build like some
surprisingly sophisticated workflows

directly and make one thing that I've
like, that I like about Zapier that

I haven't been able to figure out and
make I'm sure it's possible is that

is using timers, like, okay, you get
this trigger, wait a day, check to

see if you can send them a message, if
so, send the message, and then start

another timer that lasts however long.

And it's kind of a
pattern that I've noticed.

At lots of different
companies that I've worked at.

And maybe this is like a
potential startup somewhere.

Someone can take the idea.

The problem is there is some event
that's happening or some major thing

that's happening and you want to trigger.

Automations that are time
based that surround that event.

So in our case, we're going
to have a paint project.

And two days before the project
happens, we want to send an email.

That's like, Hey, we're coming in two
days, one hour before the start time

on the first day, we want to send a,
Hey, here's the crew that's coming.

Here's a picture of the crew, whatever.

During the event, every single day, we
want to send like these daily updates.

After the event, we want to send a
request for reviews, very similar

to in vacation rentals, where you
have a booking that's coming up

and you want to message the guest.

And you'll say like, Hey guest,
here's the wifi password.

And here's the like lock code.

And then after they check in, you
want to say, Hey, how's it going?

Do you need anything?

And after they check out similarly,
you want to say, Hey, can you send a.

Send us a review or like, you
know any feedback about your stay.

So these like I don't know.

I feel like there's, there's a
platform probably where you can build

just a series of events that happen
around a start date and end date.

And those can act as like a template
that will fire off triggers that

happen at all those different points.

Colin: Because the edge cases are
what happens if we move it out a day.

If we cancel, we don't want
the other things to happen.

Like if it's downstream, if someone
isn't going to be home to let in the

crew, so it needs to shift by hours,
but then it can't be on a weekend.

Like there's so many little things
where it's like, actually, if my house

is being painted on Friday and Monday,
I probably do want the Saturday email.

But if the job ends on Friday,
Maybe all the emails go out on

Friday or maybe it's still Saturday.

And I see this with e commerce, less
like subscriptions to like, I, I do

a subscription box for food delivery.

And like, I have to pick my meals on a
certain day and sometimes I'm not going

to be here on a Tuesday, so I have to.

change it to a different day.

And I can only imagine, I mean, that
one's a little bit simpler cause we're not

trying to coordinate people's, like you
were mentioning all those calendars too.

Like now do we even have the crew
available to do those things?

Yeah.

I wonder if there is a
service out there for that.

Immediately I start thinking about,
cause I think sidekick has this

concept of like groups of tasks and
so you could cancel the entire group.

And you can schedule them too,
but then you got to make sure

you get your time zones, right?

There's so many things that can
go wrong and if you did everything

relatively then it kind of works
But time zones will still be there

CJ: Yeah, we are using sidekicks
like scheduling for some stuff, like

you can send a scheduled message.

And we're using it for like debouncing a
couple of things and I don't know, we've

got like a couple of features in there,
but yeah, maybe we should look into that.

I like that idea of like, okay, as
soon as a project is scheduled and

locked in, then we just like schedule
a template that has like series of.

Jobs.

And at any point you can just like
cancel the whole group and then, or

like update the entire group, basically
just like delete them all and then

generate them again or something.

Colin: Yeah.

CJ: yeah, that's a good idea.

We built it basically from scratch using
DJ celery, like the Django Cron job tool

and a bunch of database calls at my VR.

But

Colin: that's more of

like

a polling and should I send something?

Should I send something?

I really like the evented way of doing
this, but then there's a lot that

could go wrong too.

So you almost have to event and
then verify that this should still

be sent before you send anything.

Like, am I still valid?

CJ: Yeah, the way that we built it there
was like, we built the polling, like the,

we built the event, the eventing on top

Colin: Mm hmm.

CJ: So like we had a job
that ran like every minute

Colin: Event emitter.

Yeah.

CJ: would check.

Yeah, exactly.

It would check the database, like,
and then based on the statuses of

different things and the timelines
of things, it would just fire events.

Yep.

And then those events were.

Then everywhere else in the entire
application, you can build it as like,

just like a subscriber or consumer of all
the events and say like, Oh, you know,

this happened, let me go fire off these
emails or Slack messages or whatever

Colin: Nice.

CJ: later on.

Yeah.

Colin: Yeah.

These are the things they
don't teach in bootcamps.

CJ: Yes.

Colin: These are the things
that only experience can can do.

But I think these are like kind
of fun questions for like more

real world interview questions.

I would think like, Hey, you need
to send an email when a job is done.

Like, what are the ways you could do it?

What are the trade offs?

I like that.

CJ: Yep.

And then what happens?

Yeah.

What happens when it moves and yeah.

Colin: I think that's much better

than like,

you know, reverse this binary tree
that you'll never do in this job ever.

CJ: right.

Yeah.

Yeah.

Colin: Proof to me that you've written,
that you've written all the leak

code problems and all that stuff.

CJ: Yeah.

Speaking of leak code,
you're learning game engines.

What's going on with

Colin: Yeah.

So for work, I'm trying to figure
out, we have a good sense of which

game engines are most popular.

With game developers, but then you
always have those, again, the long tail

of game and, you know, just like APIs.

And so I'm trying to decide
how we're gonna do integration,

like, tutorials, mostly.

We're not, do we create like a starter
for Unity, a starter for PlayCanvas?

There's a lot of these HTML5 ones.

Play canvas kaboom, things like that.

So just looking to kind of make it
easier for people to get started.

We released the docs at GDC and then
it's been fun to watch in discord.

Like a lot of people just figuring it
out and figuring out what they can do.

And I'm going to be taking all of
that and compiling it into the next

series of tutorials of like, yeah,
we forgot to tell you how to do this,

even though it's just right there.

Like it's in, it's in the SDK.

People have figured it out, but
we could do a tutorial around it.

Yeah.

I'm excited to do a bunch
of video content around it.

So part of that is learning Unity
because Unity requires not only our

SDK, but you also have to drop something
into Unity to talk back and forth and

almost actually event, you have to omit
the events from discord into Unity,

into your game and then catch them and
then respond to them and vice versa.

So we don't currently give you that.

And I'm trying to think through like, what
do we do in our Unity games that we can.

Kind of open source.

And then we want to talk, like,
we're going to talk to unity too

and say, Hey, dev rel over unity.

Like, what do we want to do together so
that they can maintain the unity piece?

We can maintain the discord piece.

So I don't have to become, again, it's
this exact same problem with the API.

It's like, we cannot be experts
in all of these all the time.

Maybe this is where some of our partners
like we have some of our partner

activities are built in play canvas
Cocos there's there's there's a lot out

there good dough It was cool at GDC to
like go and see what people are using

for all these different things, too But
yeah, mostly just having fun with it.

My first unity game is a cube that spins
in 3d space That's it's all it does

but it's a it's a start I think the
goal is to like every person who joins

Should get their own cube and we'll
just see if we can get that to run.

And then you run into the party kit
problem of, now CJ's cube moves, how do

we tell the other cubes that CJ has moved?

CJ: Mm Hmm.

Colin: turns out all these problems
are the same at the end of the day.

CJ: Yep.

Yep.

Yeah.

We're putting boxes.

Usually we're putting boxes on
the page, but you put a cube on

Colin: true, 3D boxes.

CJ: this is the future.

Colin: cameras, I mean that is
the biggest difference, right?

It's like you're like rendering
cameras and then moving the camera

versus moving the cube yeah, it's
it's fun at the end of the day.

We're getting to make some games.

So I think that's gonna be fun

CJ: What a cool opportunity to, to just
learn lots of different game engines.

Like I, I assume you'll come away with
just like if nothing else, like a hello

world level understanding of all the
different game engines and like how to,

you know, from supporting people and
answering questions and building tutorials

and demos, like what a cool opportunity.

Colin: I won't steal Shae's thunder, but
she's working on a really cool series

as she's the other dev rel at discord
Around gaming so that's all I'll say for

now, but for the actual Like tutorials,
I'm trying to decide like it feels

like it falls under my job description.

So I'm trying to figure out like Does
it make sense for me as DevRel at

Discord to be releasing like a little
tutorial or video on each of these?

Or do I go maybe stream on my own
and, you know, in my own time and

do the Colin learns all the game
engines, you know, late night

edition and do it off, off work time.

So, yeah, maybe a little bit of both.

We'll see.

CJ: Yep.

Opportunity to strike a balance
and and also, like, network

and connect with other teams.

That'll be cool.

Colin: Yeah.

This is the how do you avoid burnout
when you're chronically online?

CJ: yeah.

Yeah.

Exactly.

Colin: cool.

Awesome.

CJ: Good episode.

Let's wrap it there.

Colin: Sounds good.

Where can people find notes for the show?

CJ: yeah.

Head on over to buildandlearn.

dev to check out the links and
resources that we mentioned.

And yeah, if you're feeling generous, why
don't you head over to your podcast player

of choice and drop in a five star review.

And if you leave a review, let us
know let us know how we're doing.

Give us some feedback.

We'd love to hear from you.

And yeah, we are just over 40 episodes
now, so we have been pretty consistent.

It feels good.

Colin: 1 percent

CJ: yeah, I guess.

And yeah, until next time

Colin: Alright, we'll see you next time.

CJ: bye friends.