In this episode, we'll touch on office setup and soundproofing, with a focus on effective techniques and materials. We talk about the challenges and strategies in finding non-technical co-founders for startups, emphasizing the importance of shared values and complementary skills. The episode also delves into the impact of AI on the tech industry, particularly concerning recent layoffs. Additionally, we discuss technical topics like API documentation, memory management in Ruby and Rails, and the art of content creation and screencasting.
Resources:
Resources:
- Google Music FX - Text to Music https://aitestkitchen.withgoogle.com/tools/music-fx
- Hammerstone Dev Podcast - https://hammerstone.dev/podcast
- Tweets mentioned: https://twitter.com/cjav_dev/status/1742909106795528581
- Job Boards We like:
- Stripe OpenAPI https://github.com/stripe/openapi
- ScoutAPM - https://scoutapm.com/
- Screen casting course - https://screencasting.com/
- KeyCastr - https://github.com/keycastr/keycastr
- Keyboarding Videos
Creators & Guests
What is Build and Learn?
A podcast about software development and developing ourselves as software engineers. Hosted by CJ Avilla and Colin Loretz.
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.