December 1, 2023 • 49 mins
Welcome to a lively conversation where we turn the spotlight on the oft-overlooked powerhouse of web development - state machines. We'll share our insights, experiences, and the reasons why we think state machines are the secret sauce to simplifying complex logic. If you've ever felt bogged down by the complexity of transitioning systems between states, you're in for a treat as we illustrate how state machines can be your knight in shining armor in the realm of code development and maintainability.
We're thrilled to welcome Elise Schaefer, our new podcast host, who has stepped into her role with immense enthusiasm and a deep passion for Ruby. She brings with her a fresh perspective and an eagerness to shape engaging conversations with members of the Ruby community. As she doffs her hat to the well-structured platform left behind by Brittany Martin, Elise also shares how she's tweaking it to align with her style.
So, what's the magic formula to recognize the need for a state machine? We believe the answer lies in the presence of state in a database column or the use of enums. Listen as we traverse through the use of timestamps and callbacks in state machines and how they capture crucial nuances in the code. We also share our excitement on the immense potential of future changes in languages and how this could revolutionize web development. So, buckle up and join us on this exciting adventure as we unravel the power of state machines and the future of programming.
Honeybadger is an application health monitoring tool built by developers for developers.
Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 2 (00:01):
This is remote, have you any remote ideas to the
meaning of the word.
Speaker 3 (00:08):
Andrew couldn't last, I lost it.
Speaker 1 (00:11):
I have talked to you more today than I have, and
we're more this week than I havein a while.
Speaker 3 (00:16):
Maybe even when we were in Amsterdam together every
day, like every minute.
Speaker 1 (00:21):
Well, conferences these days are a little hard for
me.
Now I need to get the DHHhoodie and go hide in a corner
at some point.
Speaker 3 (00:29):
Well, I'm excited for this episode because, as you
might have recently learned, theRuby on Rails podcast has
passed the baton.
Brittany Martin, who was theRuby on Rails podcast host and a
really good friend to all of ushere at Remote Ruby decided to
(00:50):
enter a new step of her life andtoday we have the person taking
the baton from her, so I wouldlike to welcome Elise Schaefer.
Speaker 2 (01:01):
Thanks for having me.
I'm very excited to be here.
Speaker 3 (01:03):
Well, really grateful that you joined us today.
Elise actually reached out tous.
I just thought that was reallycool, because one thing that's
really cool about Rubypodcasting is, historically, I
mean, hasn't felt like usagainst someone else.
It's always just been like abunch of people with different
takes lifting up the samecommunity.
(01:25):
So cool to keep that going andexcited to get to know you and
along those lines, would love tomaybe give you a moment to
introduce yourself and, yeah,maybe just kind of how you got
into Ruby and into hosting theRuby on Rails podcast.
Speaker 2 (01:42):
Sure, so my name is Elise Schaefer.
I've been doing softwaredevelopment professionally since
2010.
I've been using Ruby for prettymuch that entire time.
I started out as kind ofworking in like a government
consulting type deal and thework that I was doing was kind
(02:03):
of like application developmentfor government agencies right to
do like permit tracking andstuff like that Not super
complicated stuff but it's likegoverned by a big regulations
and so the regulations make itmore complicated than maybe it
needs to be.
But that's where I learned Ruby.
That's where I learned Ruby andI learned Rails and I sort of
fell in love with it.
I have a traditional computerscience background so I grew up
(02:24):
with computers and so that partof my story is kind of boring.
It's the route that you wouldassume someone has, so that part
of it's a little bit boring.
But I fell in love with Ruby,the first language that I
learned, where I felt like Icould guess method signatures.
I could just guess them and I'dbe right about 80 or 90% of the
time and when I was wrong Icould like change the argument
(02:47):
order and that probably be right.
So that's kind of my career.
I've worked in a lot ofdifferent industries I've worked
in consumer electronics, I'veworked in billing, I've worked
in cybersecurity, that kind ofstuff across the gamut a little
bit.
So that's like kind of thestory of my career trajectory
and I'm happy to dive into anyof that.
That's like interesting.
(03:08):
The story of taking over thepodcast is really kind of
serendipitous and it's sort oflike I had helped to organize a
panel at RubyConf RubyConf minilast year, and that had kind of
introduced me to some people andso Brittany was there for that
panel and she saw that panel andthen when she was looking for a
(03:29):
new host, I believe Jemma hadmaybe mentioned my name.
But after that panel I hadstepped kind of not on purpose,
but I'd sort of stepped backfrom the community a little bit.
At the time I was like going totake a break and then I became
a manager and sort of thingshappen.
So at the time that Brittanyreached out I was sort of
looking for a way to kind of getback into the community and do
(03:52):
something for the community.
And it's sort of a situation oflike the universe just drops
something that you've beenlooking for on your lap.
And that is sort of how ithappened.
Brittany reached out.
She said, if you're interestedin this, like, let's set up a
time to chat.
We set up a time.
We got on a call and I wassuper excited about doing it.
If there's a community that isprobably going to be the most
(04:14):
fun to interview people, it'sprobably the Ruby community.
I feel like there's a lot ofcool people who are working on
cool things and who have goodstories.
And then so we had a couple ofconversations.
I met kind of the other peopleinvolved in the show.
We went on from there.
We organized the episode whereshe kind of handed over the
baton to me and then I took overand I've been running with it
(04:35):
since for the last few episodes.
Speaker 3 (04:37):
That's awesome.
How has taking over been?
Is this your first like podcasthosting experience, sort of?
Speaker 2 (04:46):
So I did a limited run podcast thing for a
conference that I had been sowhen I lived in Pittsburgh,
there was an organization therecalled Pittsburgh Code and
Supply and they organized aconference called Abstractions
and as part of that at the timeI was like involved in Code and
Supply because I lived inPittsburgh, and in the lead up
(05:06):
to that conference we did someinterviews with people who were
going to be speaking, sort of todo like promo for it on YouTube
.
So I did a couple of thoseepisodes where I did those
interviews and that was likesort of podcast like.
But it wasn't like a long termsituation, it was like I don't
know six or seven episodes orsomething.
But this is the first time thatI've taken on sort of a full
(05:27):
time podcast situation.
Yeah, how's the?
Speaker 3 (05:30):
adjustment been Pretty good.
Speaker 2 (05:32):
I think one of the nice things is that Brittany
kind of had a lot of thingsfigured out, so I sort of feel
like I picked it up and I'm justrolling with it.
I think there are some thingsthat are still learning
adjustments, but I feel likeevery episode I get more
comfortable behind the mic, Iget more fluid in the
transitions and talking withpeople and I feel like it's
(05:53):
coming more naturally every timeI record, which is good.
I think.
Organization wise, I'm usinglike I've made some adjustments
to the template and the scriptand stuff just to sort of match
my style a little bit better,but it's been easier than I
thought it would be.
To be honest, I was like alittle bit more scared and it
turned out to be very kind of,mostly good.
Like, once you actually startrecording and you've done it a
(06:14):
couple of times you just sort offall into a flow, I feel like.
So it's been easier than Ithought it would be for sure.
Yeah, that's good.
Speaker 1 (06:22):
We did it the hard way, with no plans, no nothing,
no editing, and we just like.
Speaker 3 (06:27):
No scripts no.
Speaker 1 (06:30):
But I think we've, over time, ended up with those
same sort of systems that reallymake it kind of, yeah, we sit
down, we jump on Zoom, we talk alittle bit ahead of time and
then you know how to kind ofguide the conversation when one
topic's over, it's time toswitch things or whatever.
And those are great if you'vegot the systems, or like here's
(06:51):
a bunch of gotchas that youwouldn't expect, until you're in
the middle of recording anepisode and you probably had the
shortcut on all that, which isgood.
Yeah, I was just going to sayit's really cool To see like a
podcast like that doesn't dieand it has sort of this process
of transitioning hosts whereit's like no one wants this to
(07:12):
go away, but everybody hasdifferent phases of their lives.
So it's your turn now, which issuch a cool thing, because I
have a feeling most podcastsnever really make it to that
next step if one of the corepeople steps out.
Speaker 2 (07:29):
Yeah, kind of feels like, oh, I'm the shepherd of
the podcast Right now.
Brittany was the shepherd of itbefore and she really revived
it.
I mean, the podcast was prettymuch dead when she took it over,
so I feel a certain amount ofresponsibility to that and
maintaining the audience.
But I also know that at somepoint in the future there's
going to come a time when it'stime for me to pass the baton to
(07:50):
someone else and, keeping thatin mind too, that it's more of a
community institution like evenlike my institution me taking
over the podcast.
I have my own style for how Ido it, but I think that's
important to keep in mind tooand I try to keep that at the
forefront.
Speaker 3 (08:09):
I really like that perspective on it.
It has carried on for so manyyears.
Speaker 1 (08:14):
It's got a legacy.
Speaker 3 (08:16):
Legacy yeah.
Speaker 1 (08:17):
Yeah, it's cool, but it makes me think about open
source projects that youmaintain, or our podcast or I
don't know anything.
Really, it's like how do youmake something that sustains the
individual who might havepioneered it?
But this is important for thecommunity, and when core
(08:37):
podcasts disappear in acommunity, that's not a good
sign for people who are justjoining and looking for jobs and
whatever.
And it's amazing to see thistransition, which is kind of
rare, it feels like, but alsovery welcomed.
I just wanted to.
I feel like it was just such agood thing to happen.
Speaker 3 (08:58):
So I would be interested in jumping back a
little bit, because youmentioned like you were doing
government work when you learnedRuby, and then you went on to
mention like consumerelectronics and cybersecurity
and things like that, and I'minterested to know if you were
using Ruby in any of those roles.
Speaker 2 (09:16):
Yes, I mean Ruby has been kind of a through line
throughout my career actually.
I mean I've done some liketangential stuff off of it.
I think consumer electronics ismaybe one that's like a little
bit.
You'd be like, oh, what wouldyou use Ruby for?
So in that one it's mostly wasembedded C, so it's like writing
C on a microcontroller.
But when you're doingelectronics manufacturing you
(09:36):
have to test all of the chipsthat are printed.
You have to test the circuitboards and everything.
So those test fixtures youbuilt a test fixture that clamps
onto the board and hasconnections that is to talk to a
computer, all of the stuff onthe computer that was doing all
of the testing of those boardsand then printing reports on
defect rates and all of thatstuff.
That stuff was all written inRuby on a regular laptop using
(10:00):
just Ruby, gtk or whatever.
So that was interesting andcool.
I think a lot of people think ofRuby and the first thing they
think of is Rails.
But Ruby is useful for so manythings.
I think all it takes is just tosee it in a different light and
that can help you understandthe language better and
understand your tools better,and that's true of the other
(10:22):
roles that I've had too when Iwas working in.
This is.
My most recent role was with acybersecurity firm and they
build a platform for securityfor other businesses so you can
use them to be your securityprovider, and they have a
platform that ingests from abunch of data from sensors on
(10:44):
laptops and stuff, and then theyanalyze that data.
All of that stuff was written.
Well, most of it was written inRuby, then a Rails front end,
obviously.
I think it's a wide gamut ofthings you can do with Ruby.
Speaker 1 (10:54):
Yeah, I was going to say I remember when I was
getting into Ruby in college Iloved application security stuff
and was going to go intosecurity.
But then I realized to bereally good at app security you
really need to know how to writeapplications so you can figure
out where things go wrong.
But at the time I didn't knowanything about Ruby, except for
(11:18):
Metasploit was written in Rubyand it was the maybe still is, I
don't know one of the biggestprojects in Ruby period and
that's used everywhere insecurity testing and stuff.
So it's kind of the testamentto the Ruby.
Language is one design forhumans first, which is why I
(11:39):
love Ruby, because it's like youcan get an idea from your head.
You're thinking in the wordsthat you speak, you're not
thinking in binary, so you cantranslate an idea into code a
lot faster than having to dealwith the syntax of C++, memory
allocation and all these otherthings, especially with things
(11:59):
like active support.
A lot of times you're justwriting English that happens to
read just like your thoughtswould read, or if you were to
write it out in a spec sheet orsomething.
I think that's the magic that Ireally like about Ruby.
It can apply to anything.
Speaker 2 (12:15):
Yeah, one of the things that's interesting that
you were talking about justsparked a thought which is even
like it being built fordeveloper.
Happiness is such an importantpart, even parts of the syntax
that seem weird when you'recoming from another language,
like the dot each do right.
That seems very weird if you'reused to like for X in set.
Speaker 1 (12:36):
Yeah, or I equals, zero plus plus Right.
Yeah, yeah.
Speaker 2 (12:41):
But, like to me, that makes so much sense.
It makes so much more sense tosay here's an array, like each
item in the array, do this thingright.
That makes so much more senseto me.
Speaker 1 (12:51):
Yeah, my first time I saw like 100 dot times do this
and I was like, yeah, oh my God,like it just reads like English
.
It's amazing.
Speaker 2 (13:02):
Get the feel of like it's almost like magic, right
when it works, and you're like Ididn't expect that to work.
But maybe I should haveexpected it to work because like
, yeah, that's like what I meant, right, Like yeah, that's such
a wild thing that you'll neverexperience that in almost any
other language.
Speaker 1 (13:20):
Because, like you said earlier, you can be writing
code and you're like surelythere's not a whatever helper or
method or something.
And then you're like, but I'mgoing to try and it's like, hey,
this returned a range of allthe days in the month.
That's nuts that someone alreadythought of this and built it
and I can just like skip all ofthat logic of like I'm building
(13:43):
a calendar and I need to knowthe current day and then go back
to the beginning of the month,which might be any day of the
week, and then maybe you need tostill go to the beginning of
the week because the beginningof the month is on Friday and
you got to render a calendarthat's actually like a rectangle
and like those little thingsare like super easy in Ruby
(14:03):
often and you're like what, thisis crazy.
So, yeah, I definitely canrelate to that, which kind of I
feel like we were talking before.
This episode kind of leads usinto talking about state
machines, because we weretalking about ideas to talk
about on this episode andstarted going down the rabbit
hole of like state machine gemsDon't quite have the right feel.
(14:28):
Yet I feel like I think youdefinitely have a lot to say on
this.
Speaker 2 (14:34):
Yeah, this is a bugbear for me.
I'll take it in sort of twoparts.
The first one is state machinesand sort of an argument to
convince listeners and everyonein the industry that they should
use a state machine.
State machines are.
I think they come off as alittle complicated because when
you think about it you're likewhat is a state machine?
Like what does that mean to bea state machine?
The way to think about it isanything that can exist in a
(14:56):
specific state and thentransitions between states.
Right, that's most web apps,that's most apps that we are
building in this context, havethat sort of system you can
think about, like tickettracking, e-commerce, order flow
, subscriptions, management.
All of them have this sort offeel.
I think it's important to sortof recognize that.
(15:18):
But I've also worked in appsthat obviously should have been
state machines but were justlike a bunch of guard clauses on
every method that checks thestate and that feels very
cumbersome.
But if you don't have a goodstate machine gem or some sort
of library to make it work oryou don't know about state
machines, then that's sort ofpart of the issue.
So it sort of leads you to lookat the state machine gems that
(15:39):
exist and I think there's statemachines.
State machines.
Workflow was one of them.
There's like a few.
Speaker 1 (15:45):
It wasn't there ASM or something like that.
Aasm, access state machine yeah.
Speaker 3 (15:50):
Access state machine yeah, we use workflow at Podia
like heavily so very familiar.
Speaker 2 (15:57):
Yeah, and I've used access state machine and I've
used the state machines gem, Ithink, or the two that I've used
.
But most of them work in sortof a similar way, which is they
define a bunch of methods thattake blocks that then let you
set specific states and then settransitions for which
transitions are valid, with ablock that determines what
happens on that state transition.
(16:19):
So that's sort of like the idea.
This can actually be fine formost apps.
The problem is that if you havean app that has like a dozen
states or something, these statemachines can get very large and
if they're all in the samemodel, then that model can be
thousands of lines of code andthen that becomes like a
nightmare to keep track of andit also means that when editing
(16:40):
that class you sort of have tothink about like sort of one of
the benefits of state machinesis that when you're working in
them you only have to thinkabout the states that you were
looking for, the transition fromright, like that's kind of one
of the benefits of them.
But if all this code is like inthe same class and it's all kind
of mixed together, then youstill have to sort of hold the
whole thing in your head, whichis not great, so yeah, so this
(17:01):
is like a thing that I'm veryinterested in like playing
around with and experimentingwith kind of on my own and
trying to see if I canbrainstorm some better
approaches or better ways atlike modeling state machines and
inter rails in an active recordbacked app.
So I'd love to pick your brainson what your experience has
been.
Speaker 1 (17:21):
For one.
It's sort of like you know whenyou're reading that code if
you've never edited before andyou see all the guard clauses,
like you're saying, like youhave to reverse engineer the
state machine that's notstrictly defined anywhere, which
can be incredibly hard to wrapyour head around, and you may
(17:42):
never wrap your head around itand chances are you will end up
with transitions that don't endup in the right state or
whatever.
That stuff can easily happenwhen you don't have it like
defined anywhere.
So, yeah, I think before theepisode you said something like
if you've got a model that hasstate or status as a column on
it, you should be using a statemachine.
Speaker 2 (18:03):
I thought that was really good.
You know it's a little bit of asnarky kind of comment, but
yeah, I that's one thing that Ibelieve.
I think if you see state inyour database column, that is a
clear sign state or status.
It's a clear sign that what youhave is a state machine that's
just being hidden.
If you're not currently using astate machine, jam or some some
sort of state machine for it,that's a very, very clear sign
(18:25):
and I think, like it would makeyour code more maintainable,
easier to understand, easier toreason about.
It has so many benefits tomodeling it that way.
That's the number one way toknow that it's a state machine.
I'm sure that there are otherways that you could pull out
hidden state machines, butusually when I see state on a
model and I don't see statemachine, I like know I'm in for
(18:45):
a hard debugging time.
Speaker 1 (18:48):
Yeah, or anytime an enum is used, that's a good sign
that, like you know that you'restoring states, but having a
clear definition of the statehas these transitions to these
others, Because the enums areliterally like here's zero, it's
this name.
It's one is this name, two isthis name and there's no context
(19:09):
around it, which is where thevalue of the state machines
really comes into play.
The states themselves are onlya sort of a required necessity,
but it's really the transitionsor the key piece.
These are the options you havefrom here and that's what you
need to care about.
Speaker 2 (19:26):
It also makes them easier to test too, because you
know what the discrete statesare.
Speaker 3 (19:32):
If you're like most devs, too much of your time gets
sucked up with downtime issues,troubleshooting and error
tracking.
How can you spend more timeshipping code and less time
putting out fires?
Honey Badger is how it's asuite of monitoring tools
especially for devs.
It's the only system thatcombines error monitoring,
uptime tracking, cron andheartbeat monitoring into a
(19:56):
single clean, fast interface.
Sure, you could get familiarwith any interface, but why
waste your time learning someFranken system interface that
looks like an airline cockpitwhen what you need is clarity
and speed?
You won't know if Honey Badgerwill really save you time and
trouble until you see how itworks in your own tool chain.
With two lines of code and fiveminutes you can see for
(20:19):
yourself.
Honey Badger automaticallyhooks into popular web
frameworks, job systems,authentication libraries and
front-end JavaScript, evenfixing errors before your users
could even report them.
Five minutes of your time witha free trial is all it will take
to see if it works for you.
It just might be the best fiveminutes you've spent in a while.
(20:40):
Check it out at honeybadgerio.
Another thing I find myselfimplicitly a lot is timestamps A
state like oh yeah, like apublish dad or something.
Yeah, I find myself relying on.
Well, if this timestamp ispresent, that means it's in this
state and that's often assignedto me, like, oh well, I can
(21:02):
still track those timestamps andhave a state like a state
machine that pushes thetimestamps.
It's just part of its ownworkflow.
That's a very good point.
Speaker 1 (21:11):
Yeah, Even something as simple as yeah, you've got a
draft post that needs to bepublished, but a side effect of
publishing is we need to sendout notifications or do
something like that.
It's not even state itself,it's like a callback of this
transition.
This move from these two statesneeds to do some additional
(21:33):
work, not just update the columnor whatever.
Probably anytime you find thosemethods that are like hey,
we're going from A to B and thisstuff happens along the way.
There you go.
Could be the tiniest statemachine, Could be two different
states, but still important.
Speaker 2 (21:50):
Those transitions are like the value of a state
machine is codifying thebehavior that happens on the
transition.
That is the value in it.
That's like all the power thatyou get out of it and being able
to reason about that in apragmatic way.
It's such a game changer fordevelopment, I think.
Speaker 1 (22:07):
Yeah, because the nuances creep up really fast.
Where you have using thatsimple example of going a blog
post goes from draft topublished, as that step happens,
we send notifications.
But that's not reality.
Reality is you'll publish theblog post and then someone's
like, oh shoot, we published ita week early, we need to go back
(22:29):
to draft, or something likethat.
Then we're like next time maybewe don't want to send
notifications.
There's actually an extratransition in there that skips
notifications or something, andyou have to keep that in mind.
If you don't use a statemachine, you can easily miss
those extra transitions.
Or maybe it's another state ismissing.
(22:52):
You discover Maybe thenotification step is.
This happens then immediately,once that's done, triggers the
published state or something.
We just skipped thatintermediate state and we
probably should introduce aformal thing for it.
I feel like that's anotherthing.
People often don't model wellenough, or something.
Speaker 2 (23:12):
One of the things that I think is interesting in
what you were saying there isyou're not using a state machine
and you're trying to model allthis stuff.
Now you've got all these hiddenedge cases that you probably
don't know about.
If you try to model a statemachine on top of it, you have
to deal with those edge cases,because in the draft publish one
, it's maybe not that big of adeal to just break those edge
(23:33):
cases and not care If it'ssomething like subscriptions
management, where you've gotcustomers who are depending on
some behavior that you didn'tknow you would codified.
Now to model the state machine,you've got to figure out how to
do that.
That can be very challenging ifyou didn't start with a state
machine to begin with or veryearly on, decide that it should
(23:53):
have been a state machine.
Speaker 1 (23:55):
Do you have any advice on how to break an
existing system down into astate machine?
If somebody is like you knowwhat.
You got a really good point.
I didn't use one, but I shouldbe.
Speaker 2 (24:07):
This is a difficult one.
It's very difficult topiecemeal it right.
You have to eat the whole frogat once.
Basically, my advice would beto look at some of the current
Ruby state machines.
Depending on what you're doing,depending on how many states
you have, they may be cumbersomeor might be daunting, but I
would look at some of the statemachine gems.
I know we mentioned workflowand ASM, or ASM.
Speaker 1 (24:33):
There you go.
Speaker 2 (24:34):
I would look at those , also think this is a use case
for single table inheritance too.
I think single tableinheritance can solve some of
these problems.
That's actually one of thethings that I sort of want to do
some more exploration on,because there's a part of me
that likes the idea of having adraft postpublish, that
(24:54):
transitions it to published postor whatever that sets the state
appropriately.
There's a part of me that likesthe idea of that, but without
seeing it in something real.
I don't know if that would begood or bad.
Actually, I don't know if itwould become too un-maintainable
to have too many differentobjects.
Speaker 3 (25:12):
Yeah, it's an interesting idea, because
earlier, when you were sayingyou see people handling state as
a bunch of guard clauses, I wasactually thinking, oh,
typically when I'm trying toavoid a bunch of conditional
logic based on that, it'susually with STI, because I just
like subclass and then eachthing is its own individual
representation.
Speaker 1 (25:33):
Yeah, yeah, that's maybe one of those where it
depends on the complexity ofyour state machine.
Maybe the simpler ones get thesimpler solution but the fancier
ones get single tableinheritance or something like
that.
A little bit before we startedrecording the episode, we were
talking about even thenotification example.
(25:54):
Notifications can becomplicated on their own, and
making a notifier class that'slike this defines how all the
deliveries happen for the blogpost.
It could be SMS or browsernotifications, push
notifications or emails orwhatever.
And codifying this statemachine as an actual concept in
(26:18):
your application, not just somemethods on your model, but maybe
even having a thing that's liketransition from here to here.
It can verify that you'reactually in one of the
pre-states that's required to dothis type of transition.
I feel like there's a lot oftimes where, as Rails developers
(26:39):
, it's got to be a model or acontroller or whatever.
Have a good one.
People don't take enough timeto remember that like this is
just Ruby and you can write anyclasses you want, and if a state
machine is a critical piece ofknowledge you need to understand
in the app, make a class or amodule that expresses all of
(27:01):
that and it could be just thatand it can know that we need to
operate on a subscription andcharges and customers or
whatever else.
It is the tendency for thesehave been like it's tied to a
model.
The model has the state columnand that's what we operate on
which is limiting, I think.
Speaker 2 (27:19):
I definitely agree with that.
I think for a while, I think,Rails community has kind of gone
through phases of what is thegenerally accepted practice.
So we went from like fatcontroller and skinny model to
skinny controller and fat modeland then everybody was putting
all their logic and serviceclasses and now I guess I don't
know what the soup de jure is atthe moment.
(27:40):
But if you've got a complicatedtransition of state between
like that involves multiplemodels and like that is a core
piece of your businessfunctionality, yeah, maybe
encapsulate that into a serviceclass.
That's like you've beeninstantiating call from a state
machine transition and treat itthat way.
I think all of these things aretools that help you reason
(28:01):
about the code right.
They're supposed to communicateintent to you, and so the
reason that I like a statemachine is because it helps
communicate to me what'shappening inside the app.
Like that's the thing you wantto optimize for right, the
computer can do all of thisstuff really quickly, no matter
which way you write it right.
Like it's about who's going tolook at it in the future and
understand it and be able tomodify it or edit it and
(28:23):
maintain it.
Speaker 1 (28:24):
Yeah, because state machine kind of does is rather
than I've got a subscription orsomething and it has all of
these methods available all ofthe time, but there are guard
clauses inside of them.
You could make it not respondto cancel if the subscription is
still pending.
Cancel could just only be athing at that time and then you
(28:48):
can inspect the objects and belike, well, there is no cancel
method on the subscription andit's like, yeah, because the
subscription is not active soyou couldn't cancel it or it's
already canceled.
So why would we even give youthe ability to try to cancel a
canceled subscription?
And you guys ever seen theGilded Rose Cata?
I think James, what's his name?
(29:09):
James Edward Gray.
The second, I always rememberJagd 2 as his username.
His solution for that wasbasically including modules on
instances of the class, and soit was like each one of them
could define things that theywere capable of.
They're all cheeses or whateverit's operating on, and normally
(29:32):
every cheese would have everymethod and maybe some of them
would return true or false orhave a guard at the beginning.
But the way he had implementedit was like this one we create
the cheese and then we includethese features on just this one
piece of cheese, not like thewhole thing in general, and I
was like whoa, that's mindblowing and I don't think we
(29:56):
normally have even realized likeRuby is capable of that.
We always write instancemethods as sort of like the way
we do it, but you can make thoseas modules you include when the
class is instantiated.
You check the state and thenyou include these modules to add
features like cancel only ifthe state was active or
(30:17):
something.
And I was like mind blown.
Speaker 2 (30:20):
That is very interesting.
I might have to look at that.
Speaker 1 (30:24):
I'll put that in the notes too, because think about
that on the regular, because Ididn't even realize you could be
that fluid and flexible in Ruby.
Speaker 2 (30:35):
Did you ever see?
He had two talks that one was10 things you didn't know Rails
could do, and then one was like10 things you didn't know Ruby
could do, but one ended up beinglike 42 things and the other
one ended up being like 100things.
Those are my two favorite talksof his.
They're so good.
Speaker 1 (30:50):
They're fast too Like he covers so much ground so
quickly and you're just like Ifeel like I've seen those, but
so long ago that I really,really need to rewatch them.
Speaker 2 (31:00):
So yeah, that sounds right up my own.
Speaker 1 (31:04):
You got to find the source code for this.
But isn't it weird that we canuse Ruby every day for 10 plus
years and you're still like Ididn't know we could do this or
think about problems in this wayand even just like, yeah, what
if this method is only definedon objects in a certain state?
Makes a lot of sense, you knowespecially for like what
(31:25):
transitions are available.
And it's kind of the duck typingthis, of Ruby in general, where
it's like, well, if you give usan object, we can make sure
that if it looks like a duck andhas a quack method, then like
we don't care what it is oranything, and it kind of fits
that same philosophy.
So it's wild to be like there'sso many different ways.
(31:47):
We've never even imagined howto solve these problems yet.
It feels like we should knowthese things by now, but we're
still like discovering newthings constantly.
Speaker 2 (31:56):
And we're still getting new things, like there's
still so much to discover inwhat we already have, but we're
still getting new languagefeatures and new cool stuff
every year and it's I think thebest decision of my career was
learning Ruby.
Like it's such a good languagefor me, at least for my brain,
for how it works and thecommunity is so good.
Like you said, there's so muchto learn and so much like it's
(32:19):
nice to find new ways to get touse Ruby right.
Speaker 1 (32:22):
Because I guess with other languages you're kind of a
lot stricter on what syntax isavailable and stuff, but with
Ruby it's like so flexible to apoint where it can become
debilitating, almost whereyou're like I don't know how.
I want to solve this problembecause I took a few stabs at it
and I know that I can do betterand I don't want to ship this
(32:45):
like version that I've currentlygot.
Even though it's functional,it's not as pretty as I can
imagine it could be.
A fun little example is thispast week.
One evening I was like I hadthis idea that in your active
record models you have yourassociations and you can pass
parameters to that and customizewhatever on your associations.
(33:07):
In the notice gem that I'vebeen working on, we have like
deliver this notification byemail and then you've got to
tell it what email class youwant to use the user mailer Okay
, do you want to send whatmethod?
Do we call on it the newcomment method and then we need
to pass an arguments orparameters and it's defining
sort of all this on one longline of options.
(33:28):
One of the things was like tomake stuff dynamic.
You can give it a symbol as avalue and we'll call the method
with that same name if it exists, and that's fine.
But if you have a bunch of thosenotifications, you end up with
a bunch of methods that aredefined on the class that
everybody can access and it justkind of isn't organized very
(33:49):
well.
And I was like you know it'd beinteresting as if we could just
give it a block and you couldjust say do config and then
config, define like mailer andmethod name and arguments or
whatever, and it was literallytwo lines of code to add that
feature.
So now you can, instead ofdoing a whole bunch of options
(34:09):
in a hash, you can just do aconfig block.
And the only thing I had tochange was like we check if a
block was given to the methodand then we yield a hash to it
and you can add keys to the hashand voila, you're done.
And I was like no way, there'sno way.
This is that simple and I canchange the entire ergonomics of
(34:30):
how you like organize theseconfiguration things with two
lines of code like mind blowing.
And I've been amazed because oflike Ruby's ability to do that
with the SLs.
I guess to the thing that youdon't realize is the optional
parentheses or the methods thatcan end with an exclamation or a
(34:51):
question mark, add so much tothe language.
They're tiny but they add aridiculous amount because the
things read so much better thatway.
Speaker 2 (35:01):
Yeah, it's all of these little tiny touches in the
language that they all add up.
I remember when it was probablyfrom Ruby 1 to Ruby 2, when we
got the stabby Lambda syntax forblocks or prox or whatever.
Then we also got the hashsyntax where instead of doing
the equal arrow, you got to-.
Speaker 1 (35:22):
Yeah, the fat arrow thing.
Yeah, instead of doing that.
Speaker 2 (35:25):
you could do just the symbol colon and it would
interpolate the right thing asbeing a symbol.
That was like I remember whenthat happened and it caused a
little bit of it's a bit of akerfuffle, because if you want
that to be a string or somethingother than a symbol, you still
have to use the old syntax.
But it's so nice.
It's just this little tinynicety that, just like it,
(35:49):
improves your day and it's likeMarie Kondo right, it sparks joy
every time I think of it.
Speaker 1 (35:55):
Yes, Every time I answer this.
I very fondly remember that.
And then it also hated itbecause if you write a gem then
you have to use the old syntaxbecause you're probably going to
support people still on 1.9because it's brand new and it's
like I just want to use the newnice features because I know how
clean this code can read, but Ican't use it, which is like
(36:18):
drives me nuts.
Yeah, I remember the communitywas kind of like this is awesome
, but we hate it because wecan't use it yet.
We have enough people haven'tconverted over yet and it was
like yeah, that's an interestingproblem.
What I wonder is why don'tother languages like JavaScript
could adopt optional parenthesesor exclamations or question
(36:41):
marks at the end of method namesand no other languages like
even bother to try that.
It seems strange that theydon't care.
Speaker 2 (36:49):
It's a good question.
I don't know.
I mean, maybe the people, thedevelopers developing in those
languages don't consider thosethings to be like necessary.
Speaker 1 (36:58):
Maybe because they've never experienced it, or
something like, maybe becausethey've never experienced it,
they've yeah, I've alwayswondered that because I'm like
these tiny little parser changescould make you know for some
very much more elegantJavaScript code.
Instead of having every methodis active and you could just say
(37:19):
active question mark to meworth changing JavaScript to
support that.
Speaker 2 (37:24):
It's funny because when I look at JavaScript code
and I see something that's likeis active, there's a part of my
brain that like glitches for asecond.
Speaker 1 (37:31):
Oh, yeah, me too.
Every time it's funny becauseit's like you could just make a
small tweak to the language andall that could go away.
But I don't know.
I imagine for Java.
Yeah, just a small tweak.
Speaker 2 (37:44):
I imagine for JavaScript though it's probably
got to be much more difficultbecause, like you, got to deal
with all the browsercompatibility.
Yeah Right.
Speaker 1 (37:54):
I mean.
Speaker 2 (37:54):
I guess now it's different, because you could
just like transpile to Right.
Speaker 1 (37:59):
It's one of those where it's like to get built
into the browser for adoptionGoing to take a lot of time to
ship, all that but it's alsolike not a breaking change that
they could totally add as a newfeature or something.
But I guess they kind of didthe question mark dot, like the
safe navigation stuff, whichmaybe they just picked the wrong
character for that one, I don'tknow, reminds me a little bit
(38:22):
of one of the things that I'mlike waiting for is for Chrome
to support grid level 2.
Speaker 2 (38:28):
I forgot what is the details on that.
Speaker 1 (38:30):
I forget.
I remember reading about it,okay.
Speaker 2 (38:34):
So CSS grid is like just like the standard grid.
Grid level 2 is like sub grid,I think is what they call it.
But it's like you place a gridinside of another grid and you
tell it to accept the grid stopsfor the parent grid.
So it means that you can takethe inner grid and have it
conform to the spacing of theouter grid.
Speaker 1 (38:56):
That's interesting.
Speaker 2 (38:57):
It is useful for like a.
It's useful for a bunch ofdifferent types of things.
The problem is is that the onlybrowser that supports it
currently is Firefox.
Oh, no wait, actually I think Ithink Safari supports it as of
the latest Safari release.
Speaker 1 (39:11):
Oh, wow, safari is usually a little, a little
behind on some of those things.
Yeah.
Speaker 2 (39:16):
But Chrome is like I have no idea what it's going to
ship in Chrome, Like it's beenyears and years and years.
From what I understand, it'slike waiting a refactor of the
rendering engine or something.
Speaker 1 (39:28):
Oh joy, I'm sure that's easy, but like they're
literally building almost anoperating system, you know, in
these, in these browsers, it'skind of nuts.
Speaker 2 (39:39):
It is.
It's like a whole other.
Speaker 1 (39:41):
Yeah, I always think back to like there's a talk from
some GitHub developers thatwere, I think, designers, but
they're, you know, front enddevelopers working on the diff
screen and trying to justdisplay a diff with red and
green highlighted code.
And they were like basicallythe talk was them reading the
internals of the Chromium enginebecause they were like, well,
(40:05):
if you've got million lines ofcode in a diff and you're trying
to display all that, you can'tput like a span around every
single character or whateverthat you're trying to highlight.
And if we do classes, that'svery inefficient, ids are faster
.
But if we use a tag like theitag that nobody is using or
(40:27):
we're not using anywhere else,then like that's the most
efficient.
And they're like we'rebasically just trying to style
smh2ml and then ended up, likein the internals of WebKit or
whatever, trying to understandhow to efficiently write CSS
that would render like a giantpage and I was like that sounds
(40:49):
like quite the rabbit hole to godown.
Speaker 2 (40:51):
Yeah, that's got to be incredibly challenging, like
when you get to the point wherethe thing you want to render you
have to like go and look at howbrowsers at the source code for
browsers and how they are doing.
Speaker 1 (41:04):
It's like if you're doing something in Ruby and it's
tech faults and you end up inRuby's C source code trying to
debug what you're doing, you'reso far in the weeds that most
people probably would stop andjust like all right, let's
change what we're doing instead.
Yeah, do you have any more hottakes on state machines to draw?
Speaker 2 (41:22):
No, just that people should use them.
I mean I think they are vastlyunderutilized.
That's what I will say.
Speaker 1 (41:28):
I definitely agree with that.
Even just if you are trying towrap your head around how
something works Stripesubscriptions show their flow of
statuses and states and stuffJust draw out what you're trying
to do on paper in state machineor like a flow diagram format
that you will really understandthe problem way better than
(41:52):
trying to read the sloppy codethat tries to replicate that
without really defining thestate machine.
It can be a pretty goodeye-opener because then you
might realize, like I got abunch of guards Don't make any
sense, because we're trying toprotect from using the wrong
state to call this thing.
It's like we just flip that anddo ensure that it's in these
(42:13):
states before we do this stuff.
Then you might realize there'sa bunch of code you could
reorganize, throw away whatever.
It seems like a very good thingthat you know.
I don't remember if in computerscience we, like I know we did
algorithms and stuff, but Idon't know if we spend a ton of
time on state machines or not inschool.
Speaker 2 (42:34):
I don't remember spending a lot of time on state
machines in school.
So the place where I reallylearned about state machines was
doing the consumer electronics,like embedded programming,
because, like everything you'redoing in, there is a state and
the state transition happensbased on like a button press or
a sensor input or something.
But it's just sort of funnybecause I feel like no matter
what industry you go into orwhere you go, like programming
(42:56):
is kind of the same.
It's the same tools, the sameideas, the same concepts applied
to different constraints.
So I don't remember learningabout them in school, but I feel
like most of what I've knownnow I learned after graduating
and I learned by actually doingso.
Speaker 1 (43:12):
Yeah, we had a couple electrical engineering classes
that were required in our CSdegree and I remember like we
designed a CPU, like a tinylittle CPU, from scratch, kind
of thing, and it was like it wasactually really fun because,
similar to the state machine,you're kind of working in that
mindset.
Then also the cool thing waslike, okay, you're sending these
(43:36):
eight bits of binary into theseeight slots, and then they
showed us the like jump fromthere to assembly, which is like
it's just a little word thatrepresents these bits, and I was
like, oh, that's cool.
And then they showed us to likegoing from assembly to C, and
it was like, oh, c is just likea little abstraction over the
(43:57):
assembly.
Like I can convert the C callinto the exact same binary or
whatever.
I don't remember most what wedid back then, but it was like
what?
It's just little abstractionsover layer, over layer.
And then at some point youdon't have to think about any of
it, even memory allocation,because you write Ruby.
(44:17):
So like, wonderful.
But going back down the stack,a bit like grab one of those
kids electronics projects andlike do some of that, because
you'll probably end up learningstate machines or whatever in
those projects.
Speaker 2 (44:31):
Who knows?
I think there was something yousaid that is maybe a good
starting point.
If you have a thing whereyou've got a state column and
you've just got a bunch of guardclauses, I like what you said
about just draw it out, that isa very good first step.
That will give you a clear signof where maybe some pitfalls
are and it'll actually help you.
If you choose one of thesestate machine gems or if you
choose to go the STI route orsomething.
(44:52):
It'll probably help you to makesure that you got everything
sorted out so you can make thattransition a lot easier.
Speaker 1 (45:01):
Yeah, I'm remembering that maybe in our algorithms
and data structures class we hadto model a like a vending
machine, and it was basicallylike you selected a one and it's
a dollar.
So the state machine is westart with the state of zero and
they put in a nickel and we goto five, and then we go to
(45:23):
whatever and then eventually thetransition opens up.
That's like you put in a dollaror more so we can go actually
execute the thing, but untilthen you're stuck in a loop of
waiting for more money to beinserted because we cannot give
you the thing.
But we also have the ejectbutton to like refund you all
(45:44):
the money and go back to zero.
But then it's like you open upthat state transition to like
okay, now we can give you theitem that you purchased, but it
goes into another thing which islike if we subtract the dollar
from the amount in the machine,maybe you put in the $20 bill,
so we need to dispense howevermany quarters or something in
(46:04):
afterwards.
And it's like it was just a tinylittle example that kind of got
you to think about like this isa state machine, a simple one,
but one that you interact withall the time and you can really
understand it completely andit's trivial but yet shows you
quite a few of those things,because somebody could put in a
hundred pennies or a $1 coin or$5 and you get kind of all those
(46:28):
different options to see likethere's loops if they put in
less and then just keep in thisloop until this thing is
available and so on.
So I think that's kind of avery common first introduction
to state machines.
But you can probably Googlethat and find a good tutorial on
that or something.
Speaker 2 (46:47):
Yeah, I had a friend who asked me a little bit ago
about state machines and I wantI think that that's a great
example, because what you'retalking about is you're sitting
there waiting in a loop, and thequestion that I got was like
what is the difference betweenlike something happening within
the system and somethinghappening from a user?
Speaker 1 (47:06):
Yeah.
Speaker 2 (47:07):
I was like, well, there is no difference, right.
Like the difference is likesomething happens, it triggers a
thing that transitions thestate.
That thing could be the userpresses a button or we get
another coin or whatever.
But like that example, becauseit's sort of it treats it like
you're still sitting in a loopjust waiting for the user to
give you another quarter, andthat's the same as sitting in a
loop waiting for API call tocome back or something.
Speaker 1 (47:29):
Yeah, and that's how video games work.
They're just like an infiniteloop and they're like draw
whatever screen and we just keepupdating it.
But it is funny to think aboutthat because it's like, yeah,
the web server is just waitingfor a request, but we never even
like, as Rails developers, likewe never, ever touch that.
We're just like here's arequest and we just handle the
(47:49):
event happened and we go do thatand we like are just one leg of
that loop or whatever, which isinteresting.
Speaker 2 (47:58):
I've never thought about it that way, but that is
kind of how it is, Like that'syeah, that's like breaks the
problem down where you're not.
Speaker 1 (48:05):
You're no longer responsible for the loop.
You're just doing the job ofinput and output and we just
take whatever you gave us andgive you whatever you expect
back, and it's not ourresponsibility for the outer
loop.
That's Nate Birkopeck's job onPuma.
Yeah, okay.
Speaker 3 (48:27):
We're running up against time here, but before we
wrap up, first, really gladthat you came on today and hung
out with us.
Where can people find youonline?
Speaker 2 (48:39):
So I'm off most social media, but I do have a
website.
So you can find me at EliseSchaefer dot com.
You can obviously find me onthe Ruby on Rails podcast, and
that is at the Ruby on Railspodcastcom.
I mean, in terms of socialmedia, the only one that I
really still have is LinkedIn.
I also have Strava, cycling andstuff, so if you're a cyclist,
(48:59):
you can find my Strava.
My Strava is linked on mywebsite, but I'll include it for
the show notes too.
Speaker 3 (49:05):
Awesome.
Speaker 1 (49:05):
Cool, all right.
Well, this has been a lot offun.
We will have more conversationsin person at RubyConf, so I'm
looking forward to that.
We will talk soon.
Speaker 2 (49:16):
Yeah, thank you so much for having me.
This has been an amazingconversation, so I appreciate it
and I look forward to chattingin person in a couple of weeks.
This is remote, have you any remote ideas to the
meaning of the word.
Speaker 3 (00:08):
Andrew couldn't last, I lost it.
Speaker 1 (00:11):
I have talked to you more today than I have, and
we're more this week than I havein a while.
Speaker 3 (00:16):
Maybe even when we were in Amsterdam together every
day, like every minute.
Speaker 1 (00:21):
Well, conferences these days are a little hard for
me.
Now I need to get the DHHhoodie and go hide in a corner
at some point.
Speaker 3 (00:29):
Well, I'm excited for this episode because, as you
might have recently learned, theRuby on Rails podcast has
passed the baton.
Brittany Martin, who was theRuby on Rails podcast host and a
really good friend to all of ushere at Remote Ruby decided to
(00:50):
enter a new step of her life andtoday we have the person taking
the baton from her, so I wouldlike to welcome Elise Schaefer.
Speaker 2 (01:01):
Thanks for having me.
I'm very excited to be here.
Speaker 3 (01:03):
Well, really grateful that you joined us today.
Elise actually reached out tous.
I just thought that was reallycool, because one thing that's
really cool about Rubypodcasting is, historically, I
mean, hasn't felt like usagainst someone else.
It's always just been like abunch of people with different
takes lifting up the samecommunity.
(01:25):
So cool to keep that going andexcited to get to know you and
along those lines, would love tomaybe give you a moment to
introduce yourself and, yeah,maybe just kind of how you got
into Ruby and into hosting theRuby on Rails podcast.
Speaker 2 (01:42):
Sure, so my name is Elise Schaefer.
I've been doing softwaredevelopment professionally since
2010.
I've been using Ruby for prettymuch that entire time.
I started out as kind ofworking in like a government
consulting type deal and thework that I was doing was kind
(02:03):
of like application developmentfor government agencies right to
do like permit tracking andstuff like that Not super
complicated stuff but it's likegoverned by a big regulations
and so the regulations make itmore complicated than maybe it
needs to be.
But that's where I learned Ruby.
That's where I learned Ruby andI learned Rails and I sort of
fell in love with it.
I have a traditional computerscience background so I grew up
(02:24):
with computers and so that partof my story is kind of boring.
It's the route that you wouldassume someone has, so that part
of it's a little bit boring.
But I fell in love with Ruby,the first language that I
learned, where I felt like Icould guess method signatures.
I could just guess them and I'dbe right about 80 or 90% of the
time and when I was wrong Icould like change the argument
(02:47):
order and that probably be right.
So that's kind of my career.
I've worked in a lot ofdifferent industries I've worked
in consumer electronics, I'veworked in billing, I've worked
in cybersecurity, that kind ofstuff across the gamut a little
bit.
So that's like kind of thestory of my career trajectory
and I'm happy to dive into anyof that.
That's like interesting.
(03:08):
The story of taking over thepodcast is really kind of
serendipitous and it's sort oflike I had helped to organize a
panel at RubyConf RubyConf minilast year, and that had kind of
introduced me to some people andso Brittany was there for that
panel and she saw that panel andthen when she was looking for a
(03:29):
new host, I believe Jemma hadmaybe mentioned my name.
But after that panel I hadstepped kind of not on purpose,
but I'd sort of stepped backfrom the community a little bit.
At the time I was like going totake a break and then I became
a manager and sort of thingshappen.
So at the time that Brittanyreached out I was sort of
looking for a way to kind of getback into the community and do
(03:52):
something for the community.
And it's sort of a situation oflike the universe just drops
something that you've beenlooking for on your lap.
And that is sort of how ithappened.
Brittany reached out.
She said, if you're interestedin this, like, let's set up a
time to chat.
We set up a time.
We got on a call and I wassuper excited about doing it.
If there's a community that isprobably going to be the most
(04:14):
fun to interview people, it'sprobably the Ruby community.
I feel like there's a lot ofcool people who are working on
cool things and who have goodstories.
And then so we had a couple ofconversations.
I met kind of the other peopleinvolved in the show.
We went on from there.
We organized the episode whereshe kind of handed over the
baton to me and then I took overand I've been running with it
(04:35):
since for the last few episodes.
Speaker 3 (04:37):
That's awesome.
How has taking over been?
Is this your first like podcasthosting experience, sort of?
Speaker 2 (04:46):
So I did a limited run podcast thing for a
conference that I had been sowhen I lived in Pittsburgh,
there was an organization therecalled Pittsburgh Code and
Supply and they organized aconference called Abstractions
and as part of that at the timeI was like involved in Code and
Supply because I lived inPittsburgh, and in the lead up
(05:06):
to that conference we did someinterviews with people who were
going to be speaking, sort of todo like promo for it on YouTube
.
So I did a couple of thoseepisodes where I did those
interviews and that was likesort of podcast like.
But it wasn't like a long termsituation, it was like I don't
know six or seven episodes orsomething.
But this is the first time thatI've taken on sort of a full
(05:27):
time podcast situation.
Yeah, how's the?
Speaker 3 (05:30):
adjustment been Pretty good.
Speaker 2 (05:32):
I think one of the nice things is that Brittany
kind of had a lot of thingsfigured out, so I sort of feel
like I picked it up and I'm justrolling with it.
I think there are some thingsthat are still learning
adjustments, but I feel likeevery episode I get more
comfortable behind the mic, Iget more fluid in the
transitions and talking withpeople and I feel like it's
(05:53):
coming more naturally every timeI record, which is good.
I think.
Organization wise, I'm usinglike I've made some adjustments
to the template and the scriptand stuff just to sort of match
my style a little bit better,but it's been easier than I
thought it would be.
To be honest, I was like alittle bit more scared and it
turned out to be very kind of,mostly good.
Like, once you actually startrecording and you've done it a
(06:14):
couple of times you just sort offall into a flow, I feel like.
So it's been easier than Ithought it would be for sure.
Yeah, that's good.
Speaker 1 (06:22):
We did it the hard way, with no plans, no nothing,
no editing, and we just like.
Speaker 3 (06:27):
No scripts no.
Speaker 1 (06:30):
But I think we've, over time, ended up with those
same sort of systems that reallymake it kind of, yeah, we sit
down, we jump on Zoom, we talk alittle bit ahead of time and
then you know how to kind ofguide the conversation when one
topic's over, it's time toswitch things or whatever.
And those are great if you'vegot the systems, or like here's
(06:51):
a bunch of gotchas that youwouldn't expect, until you're in
the middle of recording anepisode and you probably had the
shortcut on all that, which isgood.
Yeah, I was just going to sayit's really cool To see like a
podcast like that doesn't dieand it has sort of this process
of transitioning hosts whereit's like no one wants this to
(07:12):
go away, but everybody hasdifferent phases of their lives.
So it's your turn now, which issuch a cool thing, because I
have a feeling most podcastsnever really make it to that
next step if one of the corepeople steps out.
Speaker 2 (07:29):
Yeah, kind of feels like, oh, I'm the shepherd of
the podcast Right now.
Brittany was the shepherd of itbefore and she really revived
it.
I mean, the podcast was prettymuch dead when she took it over,
so I feel a certain amount ofresponsibility to that and
maintaining the audience.
But I also know that at somepoint in the future there's
going to come a time when it'stime for me to pass the baton to
(07:50):
someone else and, keeping thatin mind too, that it's more of a
community institution like evenlike my institution me taking
over the podcast.
I have my own style for how Ido it, but I think that's
important to keep in mind tooand I try to keep that at the
forefront.
Speaker 3 (08:09):
I really like that perspective on it.
It has carried on for so manyyears.
Speaker 1 (08:14):
It's got a legacy.
Speaker 3 (08:16):
Legacy yeah.
Speaker 1 (08:17):
Yeah, it's cool, but it makes me think about open
source projects that youmaintain, or our podcast or I
don't know anything.
Really, it's like how do youmake something that sustains the
individual who might havepioneered it?
But this is important for thecommunity, and when core
(08:37):
podcasts disappear in acommunity, that's not a good
sign for people who are justjoining and looking for jobs and
whatever.
And it's amazing to see thistransition, which is kind of
rare, it feels like, but alsovery welcomed.
I just wanted to.
I feel like it was just such agood thing to happen.
Speaker 3 (08:58):
So I would be interested in jumping back a
little bit, because youmentioned like you were doing
government work when you learnedRuby, and then you went on to
mention like consumerelectronics and cybersecurity
and things like that, and I'minterested to know if you were
using Ruby in any of those roles.
Speaker 2 (09:16):
Yes, I mean Ruby has been kind of a through line
throughout my career actually.
I mean I've done some liketangential stuff off of it.
I think consumer electronics ismaybe one that's like a little
bit.
You'd be like, oh, what wouldyou use Ruby for?
So in that one it's mostly wasembedded C, so it's like writing
C on a microcontroller.
But when you're doingelectronics manufacturing you
(09:36):
have to test all of the chipsthat are printed.
You have to test the circuitboards and everything.
So those test fixtures youbuilt a test fixture that clamps
onto the board and hasconnections that is to talk to a
computer, all of the stuff onthe computer that was doing all
of the testing of those boardsand then printing reports on
defect rates and all of thatstuff.
That stuff was all written inRuby on a regular laptop using
(10:00):
just Ruby, gtk or whatever.
So that was interesting andcool.
I think a lot of people think ofRuby and the first thing they
think of is Rails.
But Ruby is useful for so manythings.
I think all it takes is just tosee it in a different light and
that can help you understandthe language better and
understand your tools better,and that's true of the other
(10:22):
roles that I've had too when Iwas working in.
This is.
My most recent role was with acybersecurity firm and they
build a platform for securityfor other businesses so you can
use them to be your securityprovider, and they have a
platform that ingests from abunch of data from sensors on
(10:44):
laptops and stuff, and then theyanalyze that data.
All of that stuff was written.
Well, most of it was written inRuby, then a Rails front end,
obviously.
I think it's a wide gamut ofthings you can do with Ruby.
Speaker 1 (10:54):
Yeah, I was going to say I remember when I was
getting into Ruby in college Iloved application security stuff
and was going to go intosecurity.
But then I realized to bereally good at app security you
really need to know how to writeapplications so you can figure
out where things go wrong.
But at the time I didn't knowanything about Ruby, except for
(11:18):
Metasploit was written in Rubyand it was the maybe still is, I
don't know one of the biggestprojects in Ruby period and
that's used everywhere insecurity testing and stuff.
So it's kind of the testamentto the Ruby.
Language is one design forhumans first, which is why I
(11:39):
love Ruby, because it's like youcan get an idea from your head.
You're thinking in the wordsthat you speak, you're not
thinking in binary, so you cantranslate an idea into code a
lot faster than having to dealwith the syntax of C++, memory
allocation and all these otherthings, especially with things
(11:59):
like active support.
A lot of times you're justwriting English that happens to
read just like your thoughtswould read, or if you were to
write it out in a spec sheet orsomething.
I think that's the magic that Ireally like about Ruby.
It can apply to anything.
Speaker 2 (12:15):
Yeah, one of the things that's interesting that
you were talking about justsparked a thought which is even
like it being built fordeveloper.
Happiness is such an importantpart, even parts of the syntax
that seem weird when you'recoming from another language,
like the dot each do right.
That seems very weird if you'reused to like for X in set.
Speaker 1 (12:36):
Yeah, or I equals, zero plus plus Right.
Yeah, yeah.
Speaker 2 (12:41):
But, like to me, that makes so much sense.
It makes so much more sense tosay here's an array, like each
item in the array, do this thingright.
That makes so much more senseto me.
Speaker 1 (12:51):
Yeah, my first time I saw like 100 dot times do this
and I was like, yeah, oh my God,like it just reads like English
.
It's amazing.
Speaker 2 (13:02):
Get the feel of like it's almost like magic, right
when it works, and you're like Ididn't expect that to work.
But maybe I should haveexpected it to work because like
, yeah, that's like what I meant, right, Like yeah, that's such
a wild thing that you'll neverexperience that in almost any
other language.
Speaker 1 (13:20):
Because, like you said earlier, you can be writing
code and you're like surelythere's not a whatever helper or
method or something.
And then you're like, but I'mgoing to try and it's like, hey,
this returned a range of allthe days in the month.
That's nuts that someone alreadythought of this and built it
and I can just like skip all ofthat logic of like I'm building
(13:43):
a calendar and I need to knowthe current day and then go back
to the beginning of the month,which might be any day of the
week, and then maybe you need tostill go to the beginning of
the week because the beginningof the month is on Friday and
you got to render a calendarthat's actually like a rectangle
and like those little thingsare like super easy in Ruby
(14:03):
often and you're like what, thisis crazy.
So, yeah, I definitely canrelate to that, which kind of I
feel like we were talking before.
This episode kind of leads usinto talking about state
machines, because we weretalking about ideas to talk
about on this episode andstarted going down the rabbit
hole of like state machine gemsDon't quite have the right feel.
(14:28):
Yet I feel like I think youdefinitely have a lot to say on
this.
Speaker 2 (14:34):
Yeah, this is a bugbear for me.
I'll take it in sort of twoparts.
The first one is state machinesand sort of an argument to
convince listeners and everyonein the industry that they should
use a state machine.
State machines are.
I think they come off as alittle complicated because when
you think about it you're likewhat is a state machine?
Like what does that mean to bea state machine?
The way to think about it isanything that can exist in a
(14:56):
specific state and thentransitions between states.
Right, that's most web apps,that's most apps that we are
building in this context, havethat sort of system you can
think about, like tickettracking, e-commerce, order flow
, subscriptions, management.
All of them have this sort offeel.
I think it's important to sortof recognize that.
(15:18):
But I've also worked in appsthat obviously should have been
state machines but were justlike a bunch of guard clauses on
every method that checks thestate and that feels very
cumbersome.
But if you don't have a goodstate machine gem or some sort
of library to make it work oryou don't know about state
machines, then that's sort ofpart of the issue.
So it sort of leads you to lookat the state machine gems that
(15:39):
exist and I think there's statemachines.
State machines.
Workflow was one of them.
There's like a few.
Speaker 1 (15:45):
It wasn't there ASM or something like that.
Aasm, access state machine yeah.
Speaker 3 (15:50):
Access state machine yeah, we use workflow at Podia
like heavily so very familiar.
Speaker 2 (15:57):
Yeah, and I've used access state machine and I've
used the state machines gem, Ithink, or the two that I've used
.
But most of them work in sortof a similar way, which is they
define a bunch of methods thattake blocks that then let you
set specific states and then settransitions for which
transitions are valid, with ablock that determines what
happens on that state transition.
(16:19):
So that's sort of like the idea.
This can actually be fine formost apps.
The problem is that if you havean app that has like a dozen
states or something, these statemachines can get very large and
if they're all in the samemodel, then that model can be
thousands of lines of code andthen that becomes like a
nightmare to keep track of andit also means that when editing
(16:40):
that class you sort of have tothink about like sort of one of
the benefits of state machinesis that when you're working in
them you only have to thinkabout the states that you were
looking for, the transition fromright, like that's kind of one
of the benefits of them.
But if all this code is like inthe same class and it's all kind
of mixed together, then youstill have to sort of hold the
whole thing in your head, whichis not great, so yeah, so this
(17:01):
is like a thing that I'm veryinterested in like playing
around with and experimentingwith kind of on my own and
trying to see if I canbrainstorm some better
approaches or better ways atlike modeling state machines and
inter rails in an active recordbacked app.
So I'd love to pick your brainson what your experience has
been.
Speaker 1 (17:21):
For one.
It's sort of like you know whenyou're reading that code if
you've never edited before andyou see all the guard clauses,
like you're saying, like youhave to reverse engineer the
state machine that's notstrictly defined anywhere, which
can be incredibly hard to wrapyour head around, and you may
(17:42):
never wrap your head around itand chances are you will end up
with transitions that don't endup in the right state or
whatever.
That stuff can easily happenwhen you don't have it like
defined anywhere.
So, yeah, I think before theepisode you said something like
if you've got a model that hasstate or status as a column on
it, you should be using a statemachine.
Speaker 2 (18:03):
I thought that was really good.
You know it's a little bit of asnarky kind of comment, but
yeah, I that's one thing that Ibelieve.
I think if you see state inyour database column, that is a
clear sign state or status.
It's a clear sign that what youhave is a state machine that's
just being hidden.
If you're not currently using astate machine, jam or some some
sort of state machine for it,that's a very, very clear sign
(18:25):
and I think, like it would makeyour code more maintainable,
easier to understand, easier toreason about.
It has so many benefits tomodeling it that way.
That's the number one way toknow that it's a state machine.
I'm sure that there are otherways that you could pull out
hidden state machines, butusually when I see state on a
model and I don't see statemachine, I like know I'm in for
(18:45):
a hard debugging time.
Speaker 1 (18:48):
Yeah, or anytime an enum is used, that's a good sign
that, like you know that you'restoring states, but having a
clear definition of the statehas these transitions to these
others, Because the enums areliterally like here's zero, it's
this name.
It's one is this name, two isthis name and there's no context
(19:09):
around it, which is where thevalue of the state machines
really comes into play.
The states themselves are onlya sort of a required necessity,
but it's really the transitionsor the key piece.
These are the options you havefrom here and that's what you
need to care about.
Speaker 2 (19:26):
It also makes them easier to test too, because you
know what the discrete statesare.
Speaker 3 (19:32):
If you're like most devs, too much of your time gets
sucked up with downtime issues,troubleshooting and error
tracking.
How can you spend more timeshipping code and less time
putting out fires?
Honey Badger is how it's asuite of monitoring tools
especially for devs.
It's the only system thatcombines error monitoring,
uptime tracking, cron andheartbeat monitoring into a
(19:56):
single clean, fast interface.
Sure, you could get familiarwith any interface, but why
waste your time learning someFranken system interface that
looks like an airline cockpitwhen what you need is clarity
and speed?
You won't know if Honey Badgerwill really save you time and
trouble until you see how itworks in your own tool chain.
With two lines of code and fiveminutes you can see for
(20:19):
yourself.
Honey Badger automaticallyhooks into popular web
frameworks, job systems,authentication libraries and
front-end JavaScript, evenfixing errors before your users
could even report them.
Five minutes of your time witha free trial is all it will take
to see if it works for you.
It just might be the best fiveminutes you've spent in a while.
(20:40):
Check it out at honeybadgerio.
Another thing I find myselfimplicitly a lot is timestamps A
state like oh yeah, like apublish dad or something.
Yeah, I find myself relying on.
Well, if this timestamp ispresent, that means it's in this
state and that's often assignedto me, like, oh well, I can
(21:02):
still track those timestamps andhave a state like a state
machine that pushes thetimestamps.
It's just part of its ownworkflow.
That's a very good point.
Speaker 1 (21:11):
Yeah, Even something as simple as yeah, you've got a
draft post that needs to bepublished, but a side effect of
publishing is we need to sendout notifications or do
something like that.
It's not even state itself,it's like a callback of this
transition.
This move from these two statesneeds to do some additional
(21:33):
work, not just update the columnor whatever.
Probably anytime you find thosemethods that are like hey,
we're going from A to B and thisstuff happens along the way.
There you go.
Could be the tiniest statemachine, Could be two different
states, but still important.
Speaker 2 (21:50):
Those transitions are like the value of a state
machine is codifying thebehavior that happens on the
transition.
That is the value in it.
That's like all the power thatyou get out of it and being able
to reason about that in apragmatic way.
It's such a game changer fordevelopment, I think.
Speaker 1 (22:07):
Yeah, because the nuances creep up really fast.
Where you have using thatsimple example of going a blog
post goes from draft topublished, as that step happens,
we send notifications.
But that's not reality.
Reality is you'll publish theblog post and then someone's
like, oh shoot, we published ita week early, we need to go back
(22:29):
to draft, or something likethat.
Then we're like next time maybewe don't want to send
notifications.
There's actually an extratransition in there that skips
notifications or something, andyou have to keep that in mind.
If you don't use a statemachine, you can easily miss
those extra transitions.
Or maybe it's another state ismissing.
(22:52):
You discover Maybe thenotification step is.
This happens then immediately,once that's done, triggers the
published state or something.
We just skipped thatintermediate state and we
probably should introduce aformal thing for it.
I feel like that's anotherthing.
People often don't model wellenough, or something.
Speaker 2 (23:12):
One of the things that I think is interesting in
what you were saying there isyou're not using a state machine
and you're trying to model allthis stuff.
Now you've got all these hiddenedge cases that you probably
don't know about.
If you try to model a statemachine on top of it, you have
to deal with those edge cases,because in the draft publish one
, it's maybe not that big of adeal to just break those edge
(23:33):
cases and not care If it'ssomething like subscriptions
management, where you've gotcustomers who are depending on
some behavior that you didn'tknow you would codified.
Now to model the state machine,you've got to figure out how to
do that.
That can be very challenging ifyou didn't start with a state
machine to begin with or veryearly on, decide that it should
(23:53):
have been a state machine.
Speaker 1 (23:55):
Do you have any advice on how to break an
existing system down into astate machine?
If somebody is like you knowwhat.
You got a really good point.
I didn't use one, but I shouldbe.
Speaker 2 (24:07):
This is a difficult one.
It's very difficult topiecemeal it right.
You have to eat the whole frogat once.
Basically, my advice would beto look at some of the current
Ruby state machines.
Depending on what you're doing,depending on how many states
you have, they may be cumbersomeor might be daunting, but I
would look at some of the statemachine gems.
I know we mentioned workflowand ASM, or ASM.
Speaker 1 (24:33):
There you go.
Speaker 2 (24:34):
I would look at those , also think this is a use case
for single table inheritance too.
I think single tableinheritance can solve some of
these problems.
That's actually one of thethings that I sort of want to do
some more exploration on,because there's a part of me
that likes the idea of having adraft postpublish, that
(24:54):
transitions it to published postor whatever that sets the state
appropriately.
There's a part of me that likesthe idea of that, but without
seeing it in something real.
I don't know if that would begood or bad.
Actually, I don't know if itwould become too un-maintainable
to have too many differentobjects.
Speaker 3 (25:12):
Yeah, it's an interesting idea, because
earlier, when you were sayingyou see people handling state as
a bunch of guard clauses, I wasactually thinking, oh,
typically when I'm trying toavoid a bunch of conditional
logic based on that, it'susually with STI, because I just
like subclass and then eachthing is its own individual
representation.
Speaker 1 (25:33):
Yeah, yeah, that's maybe one of those where it
depends on the complexity ofyour state machine.
Maybe the simpler ones get thesimpler solution but the fancier
ones get single tableinheritance or something like
that.
A little bit before we startedrecording the episode, we were
talking about even thenotification example.
(25:54):
Notifications can becomplicated on their own, and
making a notifier class that'slike this defines how all the
deliveries happen for the blogpost.
It could be SMS or browsernotifications, push
notifications or emails orwhatever.
And codifying this statemachine as an actual concept in
(26:18):
your application, not just somemethods on your model, but maybe
even having a thing that's liketransition from here to here.
It can verify that you'reactually in one of the
pre-states that's required to dothis type of transition.
I feel like there's a lot oftimes where, as Rails developers
(26:39):
, it's got to be a model or acontroller or whatever.
Have a good one.
People don't take enough timeto remember that like this is
just Ruby and you can write anyclasses you want, and if a state
machine is a critical piece ofknowledge you need to understand
in the app, make a class or amodule that expresses all of
(27:01):
that and it could be just thatand it can know that we need to
operate on a subscription andcharges and customers or
whatever else.
It is the tendency for thesehave been like it's tied to a
model.
The model has the state columnand that's what we operate on
which is limiting, I think.
Speaker 2 (27:19):
I definitely agree with that.
I think for a while, I think,Rails community has kind of gone
through phases of what is thegenerally accepted practice.
So we went from like fatcontroller and skinny model to
skinny controller and fat modeland then everybody was putting
all their logic and serviceclasses and now I guess I don't
know what the soup de jure is atthe moment.
(27:40):
But if you've got a complicatedtransition of state between
like that involves multiplemodels and like that is a core
piece of your businessfunctionality, yeah, maybe
encapsulate that into a serviceclass.
That's like you've beeninstantiating call from a state
machine transition and treat itthat way.
I think all of these things aretools that help you reason
(28:01):
about the code right.
They're supposed to communicateintent to you, and so the
reason that I like a statemachine is because it helps
communicate to me what'shappening inside the app.
Like that's the thing you wantto optimize for right, the
computer can do all of thisstuff really quickly, no matter
which way you write it right.
Like it's about who's going tolook at it in the future and
understand it and be able tomodify it or edit it and
(28:23):
maintain it.
Speaker 1 (28:24):
Yeah, because state machine kind of does is rather
than I've got a subscription orsomething and it has all of
these methods available all ofthe time, but there are guard
clauses inside of them.
You could make it not respondto cancel if the subscription is
still pending.
Cancel could just only be athing at that time and then you
(28:48):
can inspect the objects and belike, well, there is no cancel
method on the subscription andit's like, yeah, because the
subscription is not active soyou couldn't cancel it or it's
already canceled.
So why would we even give youthe ability to try to cancel a
canceled subscription?
And you guys ever seen theGilded Rose Cata?
I think James, what's his name?
(29:09):
James Edward Gray.
The second, I always rememberJagd 2 as his username.
His solution for that wasbasically including modules on
instances of the class, and soit was like each one of them
could define things that theywere capable of.
They're all cheeses or whateverit's operating on, and normally
(29:32):
every cheese would have everymethod and maybe some of them
would return true or false orhave a guard at the beginning.
But the way he had implementedit was like this one we create
the cheese and then we includethese features on just this one
piece of cheese, not like thewhole thing in general, and I
was like whoa, that's mindblowing and I don't think we
(29:56):
normally have even realized likeRuby is capable of that.
We always write instancemethods as sort of like the way
we do it, but you can make thoseas modules you include when the
class is instantiated.
You check the state and thenyou include these modules to add
features like cancel only ifthe state was active or
(30:17):
something.
And I was like mind blown.
Speaker 2 (30:20):
That is very interesting.
I might have to look at that.
Speaker 1 (30:24):
I'll put that in the notes too, because think about
that on the regular, because Ididn't even realize you could be
that fluid and flexible in Ruby.
Speaker 2 (30:35):
Did you ever see?
He had two talks that one was10 things you didn't know Rails
could do, and then one was like10 things you didn't know Ruby
could do, but one ended up beinglike 42 things and the other
one ended up being like 100things.
Those are my two favorite talksof his.
They're so good.
Speaker 1 (30:50):
They're fast too Like he covers so much ground so
quickly and you're just like Ifeel like I've seen those, but
so long ago that I really,really need to rewatch them.
Speaker 2 (31:00):
So yeah, that sounds right up my own.
Speaker 1 (31:04):
You got to find the source code for this.
But isn't it weird that we canuse Ruby every day for 10 plus
years and you're still like Ididn't know we could do this or
think about problems in this wayand even just like, yeah, what
if this method is only definedon objects in a certain state?
Makes a lot of sense, you knowespecially for like what
(31:25):
transitions are available.
And it's kind of the duck typingthis, of Ruby in general, where
it's like, well, if you give usan object, we can make sure
that if it looks like a duck andhas a quack method, then like
we don't care what it is oranything, and it kind of fits
that same philosophy.
So it's wild to be like there'sso many different ways.
(31:47):
We've never even imagined howto solve these problems yet.
It feels like we should knowthese things by now, but we're
still like discovering newthings constantly.
Speaker 2 (31:56):
And we're still getting new things, like there's
still so much to discover inwhat we already have, but we're
still getting new languagefeatures and new cool stuff
every year and it's I think thebest decision of my career was
learning Ruby.
Like it's such a good languagefor me, at least for my brain,
for how it works and thecommunity is so good.
Like you said, there's so muchto learn and so much like it's
(32:19):
nice to find new ways to get touse Ruby right.
Speaker 1 (32:22):
Because I guess with other languages you're kind of a
lot stricter on what syntax isavailable and stuff, but with
Ruby it's like so flexible to apoint where it can become
debilitating, almost whereyou're like I don't know how.
I want to solve this problembecause I took a few stabs at it
and I know that I can do betterand I don't want to ship this
(32:45):
like version that I've currentlygot.
Even though it's functional,it's not as pretty as I can
imagine it could be.
A fun little example is thispast week.
One evening I was like I hadthis idea that in your active
record models you have yourassociations and you can pass
parameters to that and customizewhatever on your associations.
(33:07):
In the notice gem that I'vebeen working on, we have like
deliver this notification byemail and then you've got to
tell it what email class youwant to use the user mailer Okay
, do you want to send whatmethod?
Do we call on it the newcomment method and then we need
to pass an arguments orparameters and it's defining
sort of all this on one longline of options.
(33:28):
One of the things was like tomake stuff dynamic.
You can give it a symbol as avalue and we'll call the method
with that same name if it exists, and that's fine.
But if you have a bunch of thosenotifications, you end up with
a bunch of methods that aredefined on the class that
everybody can access and it justkind of isn't organized very
(33:49):
well.
And I was like you know it'd beinteresting as if we could just
give it a block and you couldjust say do config and then
config, define like mailer andmethod name and arguments or
whatever, and it was literallytwo lines of code to add that
feature.
So now you can, instead ofdoing a whole bunch of options
(34:09):
in a hash, you can just do aconfig block.
And the only thing I had tochange was like we check if a
block was given to the methodand then we yield a hash to it
and you can add keys to the hashand voila, you're done.
And I was like no way, there'sno way.
This is that simple and I canchange the entire ergonomics of
(34:30):
how you like organize theseconfiguration things with two
lines of code like mind blowing.
And I've been amazed because oflike Ruby's ability to do that
with the SLs.
I guess to the thing that youdon't realize is the optional
parentheses or the methods thatcan end with an exclamation or a
(34:51):
question mark, add so much tothe language.
They're tiny but they add aridiculous amount because the
things read so much better thatway.
Speaker 2 (35:01):
Yeah, it's all of these little tiny touches in the
language that they all add up.
I remember when it was probablyfrom Ruby 1 to Ruby 2, when we
got the stabby Lambda syntax forblocks or prox or whatever.
Then we also got the hashsyntax where instead of doing
the equal arrow, you got to-.
Speaker 1 (35:22):
Yeah, the fat arrow thing.
Yeah, instead of doing that.
Speaker 2 (35:25):
you could do just the symbol colon and it would
interpolate the right thing asbeing a symbol.
That was like I remember whenthat happened and it caused a
little bit of it's a bit of akerfuffle, because if you want
that to be a string or somethingother than a symbol, you still
have to use the old syntax.
But it's so nice.
It's just this little tinynicety that, just like it,
(35:49):
improves your day and it's likeMarie Kondo right, it sparks joy
every time I think of it.
Speaker 1 (35:55):
Yes, Every time I answer this.
I very fondly remember that.
And then it also hated itbecause if you write a gem then
you have to use the old syntaxbecause you're probably going to
support people still on 1.9because it's brand new and it's
like I just want to use the newnice features because I know how
clean this code can read, but Ican't use it, which is like
(36:18):
drives me nuts.
Yeah, I remember the communitywas kind of like this is awesome
, but we hate it because wecan't use it yet.
We have enough people haven'tconverted over yet and it was
like yeah, that's an interestingproblem.
What I wonder is why don'tother languages like JavaScript
could adopt optional parenthesesor exclamations or question
(36:41):
marks at the end of method namesand no other languages like
even bother to try that.
It seems strange that theydon't care.
Speaker 2 (36:49):
It's a good question.
I don't know.
I mean, maybe the people, thedevelopers developing in those
languages don't consider thosethings to be like necessary.
Speaker 1 (36:58):
Maybe because they've never experienced it, or
something like, maybe becausethey've never experienced it,
they've yeah, I've alwayswondered that because I'm like
these tiny little parser changescould make you know for some
very much more elegantJavaScript code.
Instead of having every methodis active and you could just say
(37:19):
active question mark to meworth changing JavaScript to
support that.
Speaker 2 (37:24):
It's funny because when I look at JavaScript code
and I see something that's likeis active, there's a part of my
brain that like glitches for asecond.
Speaker 1 (37:31):
Oh, yeah, me too.
Every time it's funny becauseit's like you could just make a
small tweak to the language andall that could go away.
But I don't know.
I imagine for Java.
Yeah, just a small tweak.
Speaker 2 (37:44):
I imagine for JavaScript though it's probably
got to be much more difficultbecause, like you, got to deal
with all the browsercompatibility.
Yeah Right.
Speaker 1 (37:54):
I mean.
Speaker 2 (37:54):
I guess now it's different, because you could
just like transpile to Right.
Speaker 1 (37:59):
It's one of those where it's like to get built
into the browser for adoptionGoing to take a lot of time to
ship, all that but it's alsolike not a breaking change that
they could totally add as a newfeature or something.
But I guess they kind of didthe question mark dot, like the
safe navigation stuff, whichmaybe they just picked the wrong
character for that one, I don'tknow, reminds me a little bit
(38:22):
of one of the things that I'mlike waiting for is for Chrome
to support grid level 2.
Speaker 2 (38:28):
I forgot what is the details on that.
Speaker 1 (38:30):
I forget.
I remember reading about it,okay.
Speaker 2 (38:34):
So CSS grid is like just like the standard grid.
Grid level 2 is like sub grid,I think is what they call it.
But it's like you place a gridinside of another grid and you
tell it to accept the grid stopsfor the parent grid.
So it means that you can takethe inner grid and have it
conform to the spacing of theouter grid.
Speaker 1 (38:56):
That's interesting.
Speaker 2 (38:57):
It is useful for like a.
It's useful for a bunch ofdifferent types of things.
The problem is is that the onlybrowser that supports it
currently is Firefox.
Oh, no wait, actually I think Ithink Safari supports it as of
the latest Safari release.
Speaker 1 (39:11):
Oh, wow, safari is usually a little, a little
behind on some of those things.
Yeah.
Speaker 2 (39:16):
But Chrome is like I have no idea what it's going to
ship in Chrome, Like it's beenyears and years and years.
From what I understand, it'slike waiting a refactor of the
rendering engine or something.
Speaker 1 (39:28):
Oh joy, I'm sure that's easy, but like they're
literally building almost anoperating system, you know, in
these, in these browsers, it'skind of nuts.
Speaker 2 (39:39):
It is.
It's like a whole other.
Speaker 1 (39:41):
Yeah, I always think back to like there's a talk from
some GitHub developers thatwere, I think, designers, but
they're, you know, front enddevelopers working on the diff
screen and trying to justdisplay a diff with red and
green highlighted code.
And they were like basicallythe talk was them reading the
internals of the Chromium enginebecause they were like, well,
(40:05):
if you've got million lines ofcode in a diff and you're trying
to display all that, you can'tput like a span around every
single character or whateverthat you're trying to highlight.
And if we do classes, that'svery inefficient, ids are faster
.
But if we use a tag like theitag that nobody is using or
(40:27):
we're not using anywhere else,then like that's the most
efficient.
And they're like we'rebasically just trying to style
smh2ml and then ended up, likein the internals of WebKit or
whatever, trying to understandhow to efficiently write CSS
that would render like a giantpage and I was like that sounds
(40:49):
like quite the rabbit hole to godown.
Speaker 2 (40:51):
Yeah, that's got to be incredibly challenging, like
when you get to the point wherethe thing you want to render you
have to like go and look at howbrowsers at the source code for
browsers and how they are doing.
Speaker 1 (41:04):
It's like if you're doing something in Ruby and it's
tech faults and you end up inRuby's C source code trying to
debug what you're doing, you'reso far in the weeds that most
people probably would stop andjust like all right, let's
change what we're doing instead.
Yeah, do you have any more hottakes on state machines to draw?
Speaker 2 (41:22):
No, just that people should use them.
I mean I think they are vastlyunderutilized.
That's what I will say.
Speaker 1 (41:28):
I definitely agree with that.
Even just if you are trying towrap your head around how
something works Stripesubscriptions show their flow of
statuses and states and stuffJust draw out what you're trying
to do on paper in state machineor like a flow diagram format
that you will really understandthe problem way better than
(41:52):
trying to read the sloppy codethat tries to replicate that
without really defining thestate machine.
It can be a pretty goodeye-opener because then you
might realize, like I got abunch of guards Don't make any
sense, because we're trying toprotect from using the wrong
state to call this thing.
It's like we just flip that anddo ensure that it's in these
(42:13):
states before we do this stuff.
Then you might realize there'sa bunch of code you could
reorganize, throw away whatever.
It seems like a very good thingthat you know.
I don't remember if in computerscience we, like I know we did
algorithms and stuff, but Idon't know if we spend a ton of
time on state machines or not inschool.
Speaker 2 (42:34):
I don't remember spending a lot of time on state
machines in school.
So the place where I reallylearned about state machines was
doing the consumer electronics,like embedded programming,
because, like everything you'redoing in, there is a state and
the state transition happensbased on like a button press or
a sensor input or something.
But it's just sort of funnybecause I feel like no matter
what industry you go into orwhere you go, like programming
(42:56):
is kind of the same.
It's the same tools, the sameideas, the same concepts applied
to different constraints.
So I don't remember learningabout them in school, but I feel
like most of what I've knownnow I learned after graduating
and I learned by actually doingso.
Speaker 1 (43:12):
Yeah, we had a couple electrical engineering classes
that were required in our CSdegree and I remember like we
designed a CPU, like a tinylittle CPU, from scratch, kind
of thing, and it was like it wasactually really fun because,
similar to the state machine,you're kind of working in that
mindset.
Then also the cool thing waslike, okay, you're sending these
(43:36):
eight bits of binary into theseeight slots, and then they
showed us the like jump fromthere to assembly, which is like
it's just a little word thatrepresents these bits, and I was
like, oh, that's cool.
And then they showed us to likegoing from assembly to C, and
it was like, oh, c is just likea little abstraction over the
(43:57):
assembly.
Like I can convert the C callinto the exact same binary or
whatever.
I don't remember most what wedid back then, but it was like
what?
It's just little abstractionsover layer, over layer.
And then at some point youdon't have to think about any of
it, even memory allocation,because you write Ruby.
(44:17):
So like, wonderful.
But going back down the stack,a bit like grab one of those
kids electronics projects andlike do some of that, because
you'll probably end up learningstate machines or whatever in
those projects.
Speaker 2 (44:31):
Who knows?
I think there was something yousaid that is maybe a good
starting point.
If you have a thing whereyou've got a state column and
you've just got a bunch of guardclauses, I like what you said
about just draw it out, that isa very good first step.
That will give you a clear signof where maybe some pitfalls
are and it'll actually help you.
If you choose one of thesestate machine gems or if you
choose to go the STI route orsomething.
(44:52):
It'll probably help you to makesure that you got everything
sorted out so you can make thattransition a lot easier.
Speaker 1 (45:01):
Yeah, I'm remembering that maybe in our algorithms
and data structures class we hadto model a like a vending
machine, and it was basicallylike you selected a one and it's
a dollar.
So the state machine is westart with the state of zero and
they put in a nickel and we goto five, and then we go to
(45:23):
whatever and then eventually thetransition opens up.
That's like you put in a dollaror more so we can go actually
execute the thing, but untilthen you're stuck in a loop of
waiting for more money to beinserted because we cannot give
you the thing.
But we also have the ejectbutton to like refund you all
(45:44):
the money and go back to zero.
But then it's like you open upthat state transition to like
okay, now we can give you theitem that you purchased, but it
goes into another thing which islike if we subtract the dollar
from the amount in the machine,maybe you put in the $20 bill,
so we need to dispense howevermany quarters or something in
(46:04):
afterwards.
And it's like it was just a tinylittle example that kind of got
you to think about like this isa state machine, a simple one,
but one that you interact withall the time and you can really
understand it completely andit's trivial but yet shows you
quite a few of those things,because somebody could put in a
hundred pennies or a $1 coin or$5 and you get kind of all those
(46:28):
different options to see likethere's loops if they put in
less and then just keep in thisloop until this thing is
available and so on.
So I think that's kind of avery common first introduction
to state machines.
But you can probably Googlethat and find a good tutorial on
that or something.
Speaker 2 (46:47):
Yeah, I had a friend who asked me a little bit ago
about state machines and I wantI think that that's a great
example, because what you'retalking about is you're sitting
there waiting in a loop, and thequestion that I got was like
what is the difference betweenlike something happening within
the system and somethinghappening from a user?
Speaker 1 (47:06):
Yeah.
Speaker 2 (47:07):
I was like, well, there is no difference, right.
Like the difference is likesomething happens, it triggers a
thing that transitions thestate.
That thing could be the userpresses a button or we get
another coin or whatever.
But like that example, becauseit's sort of it treats it like
you're still sitting in a loopjust waiting for the user to
give you another quarter, andthat's the same as sitting in a
loop waiting for API call tocome back or something.
Speaker 1 (47:29):
Yeah, and that's how video games work.
They're just like an infiniteloop and they're like draw
whatever screen and we just keepupdating it.
But it is funny to think aboutthat because it's like, yeah,
the web server is just waitingfor a request, but we never even
like, as Rails developers, likewe never, ever touch that.
We're just like here's arequest and we just handle the
(47:49):
event happened and we go do thatand we like are just one leg of
that loop or whatever, which isinteresting.
Speaker 2 (47:58):
I've never thought about it that way, but that is
kind of how it is, Like that'syeah, that's like breaks the
problem down where you're not.
Speaker 1 (48:05):
You're no longer responsible for the loop.
You're just doing the job ofinput and output and we just
take whatever you gave us andgive you whatever you expect
back, and it's not ourresponsibility for the outer
loop.
That's Nate Birkopeck's job onPuma.
Yeah, okay.
Speaker 3 (48:27):
We're running up against time here, but before we
wrap up, first, really gladthat you came on today and hung
out with us.
Where can people find youonline?
Speaker 2 (48:39):
So I'm off most social media, but I do have a
website.
So you can find me at EliseSchaefer dot com.
You can obviously find me onthe Ruby on Rails podcast, and
that is at the Ruby on Railspodcastcom.
I mean, in terms of socialmedia, the only one that I
really still have is LinkedIn.
I also have Strava, cycling andstuff, so if you're a cyclist,
(48:59):
you can find my Strava.
My Strava is linked on mywebsite, but I'll include it for
the show notes too.
Speaker 3 (49:05):
Awesome.
Speaker 1 (49:05):
Cool, all right.
Well, this has been a lot offun.
We will have more conversationsin person at RubyConf, so I'm
looking forward to that.
We will talk soon.
Speaker 2 (49:16):
Yeah, thank you so much for having me.
This has been an amazingconversation, so I appreciate it
and I look forward to chattingin person in a couple of weeks.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
24/7 News: The Latest
The latest news in 4 minutes updated every hour, every day.