December 3, 2024 • 32 mins
What drives a seasoned developer from Taiwan to London, and how does one translate a passion for Ruby into groundbreaking projects? Hear from Stan Lo of Shopify's RubyDX team as he shares his captivating journey and his significant impact on the Ruby development landscape. From his essential work on the debug gem and IRB to his current efforts with the Sorbet type checker and Prism parser, Stan delves into the technical intricacies of using C++ for performance and memory management. Gain unique insights into the collaborative decision-making process at Shopify that guided his transition from the Ruby LSP to focusing on Sorbet's integration.
We also tackle the hurdles of progressing Ruby's Sorbet parser to Prism and the challenges of maintaining comprehensive Ruby documentation. Discover the importance of community-driven contributions, and how small acts like fixing typos can have a profound impact on the Ruby ecosystem. Experience Stan's personal anecdotes, from climbing adventures to mastering calisthenics, and explore the innovative shift from VS Code to Cursor, amplifying his development experience through AI capabilities. As we gear up for future events like RailsConf and RubyKaigi, there's an air of excitement for community reunions and ongoing projects. Join us for a blend of technical discussion, personal stories, and a call to action for all Ruby enthusiasts.
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 1 (00:01):
Hello everyone, welcome to another episode of
Code and the Coding Coders whoCode it.
I'm your host, drew Bragg, andI'm joined today by Stan Lo Stan
.
For anyone who's not familiarwith you, would you please
introduce yourself?
Speaker 2 (00:11):
Hello everyone.
My name is Stan.
I'm a developer at Shopify'sRubyDX team.
Dx stands for DeveloperExperience, so I'm working in
the same team with Vinny Stock,who was also a previous guest of
this show, and I moved fromTaiwan to London three years ago
and then, during my work, Ipreviously mostly working on
(00:33):
Ruby SP and I actually alsowrote an RSpec add-on for it,
and then I contributed quite abit to the debug gem, even gave
two talks about it on RubyKaigi.
I'm a maintainer of IRB atRelay and right now I'm focusing
on improving Ruby'sdocumentation from different
fronts.
(00:53):
Oh, by the way, I'm also a newmaintainer of RDoC.
Speaker 1 (00:57):
That's pretty much about it Working on a lot of
stuff.
So the way this is going towork is I'm going to ask Stan
three questions.
I'm going to ask him what he'sworking on, which it sounds like
there's a lot.
I'm going to ask him what kindof blockers he has.
If he doesn't have a currentblocker, he can talk about a
recent blocker he had, how hewent about solving it.
And then the last question iswhat is something cool, new or
(01:17):
interesting that you've recentlylearned, discovered, built?
It doesn't have to be codingrelated, doesn't have to be
coding related.
It can be climbing related, butit can be coding related,
because this is code and thecode encoders, code it and we
talk about code.
So I'm going to shut up now andjust simply ask Stan what are
you working on?
Speaker 2 (01:35):
Right now my main project at Shopify is I'm
working with my teammates EmilySemp and Alex Montelove making
Sorbet the type checker for Ruby, use Prism as its parser, and
to do that I actually startedlearning C++, because that's how
(01:55):
Sorbet is mostly written in,and even a little bit of C,
because we integrate Prism as aC library.
Speaker 1 (01:59):
Interesting.
I did not know that Sorbet wasC++ behind the scenes.
Do you know the history behindthat?
Speaker 2 (02:04):
I did not know that Sorbet was C++ behind the scenes
?
Do you know the history behindthat?
So it's mostly because typechecker needs to be very fast,
and by fast I mean it can kindof index the Shopify monolith in
about a minute, for example.
That's a lot of files and to dothat they need to have good
(02:27):
memory management and everythingthat could be optimized.
So they need to go pretty lowlevel to achieve that
optimization.
Speaker 1 (02:33):
Now I remember when I had, I believe, kevin Newton on
some episodes ago, we kind oftalked about the decision to
move YJIT from C to Rust.
Was it a similar thing, whereit kind of started as a C
project and then they were like,well, c is kind of horrible to
work with because there's a lotgoing on, so let's move to C++,
(02:55):
where we get some help withmemory management, or why was it
C++ and maybe not Rust?
Or why not just straight C?
That I actually don't knowabout.
Speaker 2 (03:07):
But I will say, when Sorbet was created, rust was not
as maybe mature or popular asit is today.
Maybe if we started today, itcould be Rust.
Speaker 1 (03:19):
Same motivation of wanting the speed of a lower
level language and maybe notdoing all of our memory
management ourselves.
Exactly, very cool, very cool.
So you also have worked on theLSP at Shopify, which is, I
think, every Ruby developer'sfavorite tool in the world right
now.
But now you're working onSorbet.
How did you go from the LSP toSorbet?
(03:42):
Is that something where youwent to your manager and said,
hey, I want to try out somethingdifferent?
Did that team say we need moredevelopers who want to come over
?
How is it decided what projectyou work on primarily?
Speaker 2 (03:54):
So the DX team our team will have meetings to talk
about what are the most highimpact tasks, problems we can
solve, and then we createinternal projects based on the
team's discussion, and myprevious two projects were all
(04:14):
RubySP related.
They have set the assumptionson why we need to work on the
project and also what does itfeel like a success when to
finish the project.
So I did that for an entireyear, two different projects,
and then by the end of the firstproject I actually wrote the
(04:34):
Rails SQL blog post aboutco-navigation improvements done
in Rubysp.
We basically do the best as wecan to provide co navigation
features like go to definitioncompletion, for example, without
using any type of information,and that's when we kind of feel
(04:54):
like, okay, most of thelow-hanging fruits in this front
has been picked, and then maybemaking Sorbet using Presen as
its parser will be the next bigthing, because that will space
things up even more for Shopify.
So then I decided to move on tothat project.
Speaker 1 (05:13):
So that's your Shopify life and then your not
Shopify life.
You're kind of focused on theRuby documentation, which is an
honorable effort because we alluse it, we all love it.
But it needs some love, itneeds some updating.
What got you involved in that?
Speaker 2 (05:31):
So similar to many people in our team, we always
feel like we want to improve allthe Ruby tooling, not just
specific aspect of it, andthat's why last year and the
year before I kind of focused ondebug, gem and then IRB,
because first I feel likedebugging can be improved the
(05:52):
most, and then after that I moveon to IRB, because console and
the default repo could be veryimportant as well.
Right now IRB reaches a bit ofalmost feature parity with Pry,
for example.
I just spotted that maybedocumentation is the next thing,
because whenever I go to theofficial Ruby documentation,
(06:16):
which is docsrubylandorg andslash EN, if you read the
English documentation, that'sthe only official English
website and half a year ago it'sterrible.
It's just so hard to look atand then so hard to navigate
into it and that's why nobodyuses it and then nobody even
know that it's the officialdocumentation.
(06:36):
So I just feel like, okay, thisis the next big thing that can
be improved and that will helpevery Ruby developer.
So yeah, that's how it started.
Speaker 1 (06:48):
I agree with you.
It is so important to havereadable documentation.
As someone who hunts down weirdRuby syntax, who has the docs
open a lot, I can confidentlysay they need some love in
updating.
They can be hard to navigate.
You kind of talked about you gofor the low-hanging fruit at
(07:11):
work.
Is it the same with the Rubydocumentation where it's well,
let's just find really easy winsto start updating it?
Or is there a big team behindit?
Was is because it doesn't havemuch investment from the
community.
Speaker 2 (07:40):
And so I would say there's some low hanginghanging
fruits, because it's beenunderinvested for so long.
A lot of work needs multiplesteps to actually take effect to
the end user, and so the firstthing I tried to do is that me
(08:01):
and Colby, creator of RubyAPIorg, after RubyHacky we both became
the maintainer of Rdark, and sowe decided that To get things
starting rolling again, it'sbest to make some very obvious
visual improvements to our users.
(08:22):
So that's why we startedimproving the default theme of
RDoC, which will directly beapplied to the official Ruby
documentation.
It's kind of the first step wewant to focus on this year.
We want to make it morepleasant to read and when more
people use it, people willrealize maybe there are missing
documentation, there are typosmaybe, and then they will want
(08:45):
to get involved and that's whenwe can recruit more contributors
to this area and maybe alsomore maintainers.
Speaker 1 (08:53):
So you're kind of looking to not just get
contributions but also getpeople who are like I am willing
to take on some of themaintainer burden of the Ruby
documentation.
Speaker 2 (09:05):
Yes, the projects I work on moving from debug to IRB
to RDoC right now.
So the project itself touches alot of users.
But when going into IRB, forexample, some but not too many
projects actually use it as aplatform.
(09:26):
The biggest example is Railsuse it as the base of Rails
console.
So it's through that I realizedsometimes working on that
project may not be enough andalso I don't have enough
capacity to do that.
So it's best to find a way tobuild a community around it.
And for IRB it's actually notas easy and also not necessary.
(09:50):
But for documentation it's sucha big effort.
I feel it's something that thisapproach really needs to be
taken seriously than justco-contribution.
Speaker 1 (10:02):
So if you were thinking we want people to come
in first-time contributors, so agood first-time issue or first
contribution for someone, butalso something that isn't I
added a period here somethingthat actually has real impact,
what does that look like to you?
Or what areas do you thinkthose exist the most in?
Speaker 2 (10:23):
So for Ruby, currently we can split it into
two parts.
One part is the contentimprovement and the other part
is the more technical side,mostly centered around RDoC,
because it generates the HTMLfiles, so it controls the
parsing of the source code, itcontrols the theme, how it looks
(10:44):
like, and it controls a lot ofaspects like the SEO of the
final documentation, for example.
So we actually have manycontributors from the community.
They work on front-end, theywork on frontend, they know
frontend better than me.
They contribute small featuresto RDoC's Depot theme and there
(11:08):
are other contributors that aremore interested in parsing.
For example, we got acontribution on replacing RDoC's
Ruby parsers from using Ripperto use Prism, for example.
On the technical aspect, rdochas a lot of places to
contribute to and that's one ofthe things I aim to improve next
(11:30):
year to lay out the componentsand then different things to
improve in each component to letcontributors have a better view
on what part they may beinterested in, and then
hopefully later we can evenprovide a contribution guide for
each component, for example.
Speaker 1 (11:48):
Yeah, that's actually really cool that someone could
contribute to Ruby documentation, but in a very technical way.
It's not the same ascontributing to, maybe, the
Rails documentation, where it'swrite an article on how
ActiveRecordX works.
You can have a big impact onthe Ruby documentation by doing
very technical work.
(12:10):
Is RDoC Ruby or is RDoC anotherone of those?
Contribute to Ruby by writing C?
It's pure Ruby.
Yeah, it's pure Ruby.
That's cool.
That's even better.
Don't have to learn C or workwith C, as it were.
Speaker 2 (12:23):
I have to warn that RDoC is a very, very old project
older than the time I writeRuby, for example so it has some
legacy code you need to firstnavigate through before you can
actually make a contribution.
Speaker 1 (12:39):
I'm very familiar with projects like this.
They yield great talks.
Those can be a lot of fun too,because by needing to navigate
an older code base like that,you can kind of see Ruby's
evolution of its syntax.
And can be a lot of fun,especially if you're doing it
just for fun and it's not likeyour day job and you can just
I'm going to pick this up, I'mgoing to put it down because, ow
, my brain hurts.
(12:59):
That can be a lot of fun andalso might be a good place for
me to find some new game showquestions.
Speaker 2 (13:05):
And also, you know what tool will make it easier to
navigate?
Use Ruby SP with all thenavigation features we just
shipped this year.
Speaker 1 (13:14):
There you go.
You are helping yourself withyour work by doing your work.
Speaker 2 (13:21):
Yeah, that's the good part of working on developer
experience Every tool I improve,I can use it in another project
.
Speaker 1 (13:25):
That's super cool.
That was at RubyConf San Diegoduring community day or hack day
.
I got to work on the LSP alittle bit and it was super cool
to use the LSP to work on theLSP.
It was so Hold on, we've got toload up the LSP so that we can
continue to work on the LSP.
When you're working on a webapplication, you don't get that
(13:48):
kind of immediate feedback onyour stuff, I guess, and it was
pretty funny to be able to dothat.
Speaker 2 (13:54):
Yeah, I guess this is the biggest reason I love
anything that's built fordevelopers.
Speaker 1 (14:00):
And we all benefit from your work too, so thank you
.
So you're working on quite anumber of things, and quite a
number of impactful things.
What kind of blockers do youhave in your work?
Speaker 2 (14:09):
I can give you two blockers, one on the main job
and one on the side questPerfect.
So the main blocker about theSorbet prism work is to have
that translations support errorthe same level of error
tolerance as the original parser, if that makes sense, let me
(14:32):
give you an example.
So when you use Sorbet and youhave a Ruby file that has
certain syntax errors, sorbetcan provide you additional hints
how to fix it, and hopefullywe'll need to achieve the same
hints at the same locations withPrism.
So let me share some backgroundabout this main parser
(14:56):
replacement.
So the main work is thatSolbase current parser generates
.
When you parse Ruby files itgenerates a certain structure of
the parse tree, but whenpresent parses the same file, it
generates different structureof a parse tree.
So currently we write atranslation layer to convert
(15:17):
present structure into SOBASEcurrent process structure.
So then the rest of thepipeline can just not know about
the existence of the presentparser.
So that's what we do.
However, it's not an easy job,but we have mostly completed it.
But in the error cases, becausethere are a few ways you can
(15:42):
write correct Ruby code, thereare infinite ways you can write
incorrect Ruby code.
So right now.
The possibility is infinite.
We need to find out theeffective way to kind of match
that structure in error cases aswell, and we have been trying
(16:02):
different ways, but extremelydifficult.
That's the current blocker onthis project and I don't have
any answer on how to beunblocked.
Speaker 1 (16:12):
Yeah, that's a bit of a crazy one because you're
right, there's so many ways towrite correct Ruby, but there's
so many more to write incorrectand to be able to give that kind
of error feedback.
But the blocker you're havingis that kind of a result of
Prism being more error tolerantbecause it gives you better
feedback.
You need to account for all ofthat feedback where the old
(16:35):
parser just syntax.
We're done.
Speaker 2 (16:38):
Not really, regardless of which two parsers
you are trying to translate, totranslating incorrect files,
past results will always bedifficult because the amount of
cases you need to learn, casesyou need to learn, and also
(17:02):
because we will design goodprocess structure for correct
Ruby code, right, but we may notpay that much attention for the
structure of incorrect Rubycode.
And if you don't do that, thenyou probably don't write
documentation for those cases.
And then so every case, youneed to manually test it and
then document it, even though itmay not even be a design
decision, but you just need tocover everything.
Speaker 1 (17:24):
Everything is an understatement.
That's a lot.
That is a interesting blocker.
I don't envy you for thatblocker.
That is challenging work.
But you said you had two.
So that was the first one, andwhat a good one.
But what is your second blocker?
Speaker 2 (17:40):
So the second blocker is around Ruby documentation.
Again, as I say, documentationrequires efforts from the entire
community.
So first, on this side, I andthe rest of the team need to
find a way to motivate andencourage contributors to come
in and start helping out, forexample.
(18:01):
But on the other hand, wecurrently don't have that many
maintainers to have enoughreviewing capacity to kind of
testing, go through all thecontributions from the community
and a lot of times, as manypeople who contributed to open
source projects may know it'svery frustrating to spend a
(18:21):
weekend on a PR and then nothaving feedback in two months or
even one year.
That's the things we don't wantto see.
But at the same time, if wedon't have contributors, how can
we raise maintainers?
And also, raising maintainersmeans that not only do they need
to have the technical skillsand context about the codebase,
(18:45):
they also need to learn trustfrom the rest of maintenance and
then also the Ruby core in ways, and all of these take times.
I have been trying hard to helpout on both fronts.
That's the current major block,but I will have to say at the
RubyConf this month in Chicagowe have made some progress.
(19:08):
So right now new contributionsare coming in and then we are
talking about possible futuremaintenance candidates and
hopefully next year we will bein very good shape in accepting
community contributions.
And then we can see theimprovements on Ruby's official
websites or Ruby's officialdocumentation.
(19:29):
The improvements pace willaccelerate and then kind of
match people's expectations more.
Speaker 1 (19:38):
That's an interesting little bit of chicken and egg
problem.
Like we want more contributorsbut you don't have a ton of
maintainers to go through allthe contributions.
But in order to get moremaintainers you need
contributors.
But in order to get happycontributors you need the
maintainers.
That's tough, but I guessyou're also a solution to that.
Blocker in a way is hoping thatas much as it does stink to
(20:02):
work on something on a weekendand then have to wait two months
for feedback on it.
Hopefully the folks in the Rubycommunity are understanding of
that bit where it's hey, sorry,we've got a lot going on.
I just had a PR from RailsMerge that I opened two years
ago.
It happens I get it.
It's open source work, totallyunderstand.
(20:22):
Hopefully most peopleunderstand hey, I'm going to do
this work.
It's good work, it'lleventually go in.
Just give it time.
Do you have interestingblockers, sir?
Neither of which I'm jealous of.
Speaker 2 (20:37):
I don't think I've ever been jealous of someone's
blocker though.
Speaker 1 (20:39):
Yeah, that's true, good blockers though.
And so I guess a solution toyour second blocker, in a way,
is if anybody is listening tothe show and is thinking, hey, I
would love to give back to theRuby community in some capacity.
A great way is to reach out toMr Stan Lowe here and get on
board with contributing to RDoCand the Ruby documentation in
(21:02):
whatever capacity you're able to, and when you do that, give
them a degree of patience.
Speaker 2 (21:07):
So that's my call to action for the Ruby community
anyone listening that has thecapacity, get on that, and
speaking of contribution, if youhave limited capacity, there's
actually a certain amount oftypos or grammar errors in this
(21:29):
documentation source, directlyinside the C Ruby itself, that
you can just go find themmanually and fix.
Or I'm actually testing anapproach which is to use LLMs to
(21:52):
help correcting them in batchwith less effort.
So, yeah, you can use whatevertool and, based on my
experiments, llms are very, verygood at fixing those typos and
errors.
It takes me about half hour togo through the same document,
like same files, for exampletracepointrb, inside Ruby to
(22:13):
find all these obvious errorsand fix them and open a PR.
So if that's what you want todo and then become a CRuby
contributor there, you go.
Speaker 1 (22:25):
That's an easy way to get in.
I tried to get in at RubyshotConf Chicago.
While I was working on the gameshow.
I found a bug in Ruby and itwas cool.
I'll be able to get a commitinto CRuby.
This will be great, Turns out.
No, it's so much harder to doit via code.
I'm definitely going to go thetypo route.
That's brilliant.
Speaker 2 (22:45):
I like that, Looking forward to see your PR.
I mean, I don't review thosePRs.
It will be coming to a stoop,but yeah, I'm happy to see you
contribute Still any kind ofcontribution.
Speaker 1 (22:52):
Typos can be super distracting.
When you're reading and you'regetting into something, you see
it and it just takes your brainout of whatever you're learning
and you're like that's a typo.
So they can be very distracting.
Definitely a worthwhile effortto fix typos.
So the last question, myfavorite question, is what is
(23:14):
something cool, new orinteresting that you've recently
learned or discovered or builtor did that you want to share?
Speaker 2 (23:18):
I mentioned that I started working on Sorbate and
then learned C++.
I've never written any C++ or Cor ROS before that project, so
I actually rely heavily on thecursor editor and O1 preview
model, if I'm being veryspecific, and it's just so
(23:42):
amazing how it is able to graspthe context and then also being
super patient on teaching me allthe things I need to know about
C++ in order to make thingscompile and then not stack forth
.
Speaker 1 (24:00):
In case you've never had to work with a language like
C++ before, there's an extrastep that we don't have to do in
Ruby and that is compile yourcode.
And I remember back in highschool working with C and Java.
It took forever even smallprograms, I felt like, and it
was always such ananxiety-inducing.
You hit, run and you're justplease, don't error out, please
don't error out, please don'terror out.
(24:21):
So I am every day very, veryimpressed by all the different
AI tools that come out and howmuch better they get.
I feel like when they first cameout, they were just look at
these AI tools and I was likethey don't actually do that much
for you.
And now they're very impressive.
Andrew Mason was teaching mehow to use copilot edits in VS
(24:43):
Code and how to tell it whatfiles to use in context and what
a difference it makes when youcan say like hey, look at these
files, this is how we write ourcode.
Help me do X and the stuff itcomes up with still not 100%
perfect every time, butdefinitely can help you with the
blank slate problem or justgetting over that hump of hey,
(25:04):
how do I even get started?
Where should I start?
Speaker 2 (25:07):
it's wildly impressive so in my experience
it's basically like a senior C++developers just pair with me
all the time, 24 hours, becausesometimes I work in very weird
hours and then it's always thereand then so patient on
explaining every dumb questionsI have.
Speaker 1 (25:28):
What was the thing that got you to start using
Cursor and what were you usingbefore Cursor?
I guess I don't mean to makethe assumption that you were on
VS Code before, but how did youget to Cursor when I first
learned?
Speaker 2 (25:39):
Ruby, 10 years ago I used Veeam and then NeoVeam and
then two years ago I switched toVS Code.
So you were right, I was usingVS Code.
Speaker 1 (25:49):
It was a pretty good assumption statistically
speaking, but I just want tomake sure.
Speaker 2 (25:56):
I think half of the community uses VS Code,
according to the latest survey.
Yeah, so I was using VS Code,but at the time I used it the
copilot was not very good.
But then we heard Cursor and AIis super good and as a
developer working around DX, Ikind of need to know how good it
is and how in ways we could,for example, provide context
(26:20):
about Ruby better into feedingthese tools.
So, yeah, I gave it a try andthen at the beginning I also
like writing Ruby.
I assume maybe if you writeRails applications, it has
enough database to kind ofprovide you good suggestions.
If you are writing a LSP server, which is very few in the
(26:41):
community, it's not always thatsmart.
It's when I actually work onthis project and learn a new
language that is kind of blownaway by its ability.
Speaker 1 (26:53):
Yeah, that makes a lot of sense that you're working
in an established sort ofmainstream code base but just in
a language or maybe even aframework that you don't
understand, where it kind ofshines.
I have not worked much with C++.
Is there testing in C++ or isit all just hit the compile
button?
If it compiles rock and roll,you're good to go.
Speaker 2 (27:13):
There's definitely testing, but I would say Sorbet
is a very unique project.
It's a type checker, so ittakes another language's file
and then uses different ways toassert the expected result.
So even if I were to write itin Ruby, most of the tests and
(27:36):
expectations exist in a form offiles.
So it's very different from howwe write tests in Rails
applications, for example.
You write actual test cases.
In Sorbet, for example, testsare generated and then they will
just grab the files withcertain names and then run a
(27:56):
result.
Compare you to another filewith certain names.
I'm not sure if that's arepresentative answer that works
.
Speaker 1 (28:05):
Yeah, no, I was just curious because it sprung to
mind as we were sitting heretalking about C++ and I was just
hey, do you test in a languagelike that?
Like I said, I haven't workedreally much with compiled
languages since high school, soit's been too many years.
The other thing that I justwanted to publicly congratulate
you on is your hanging parallelor whatever you call it that you
(28:28):
recently posted on Blue Sky.
That is, as someone who dabblesin climbing and gymnastics,
stuff like that.
That is impressive, sir, ifanyone listening doesn't know
what I'm talking about.
Basically, stan hung from apull-up bar and then got his
whole body parallel to theground while hanging For one
second, which doesn't sound likea long time, but that is an
(28:48):
impressive amount of work to getyour core to be able to do that
.
Maybe if you're used towatching the Olympics gymnastics
, you're like so what Forsomeone who doesn't train as
their day job?
That is really hard work.
So super big congratulations.
Yeah, it's actually calledFront Lever, front Lever Okay, I
don't know names for things.
Speaker 2 (29:09):
Yeah, that's fair.
So I think we climbed togetheronce at last year's UB Conf in
San Diego.
And at that time I just climbed.
And this year, for some reason,I started getting into the
world of calisthenics I hope Ipronounce it right, yeah,
calisthenics.
So it all started from one armpull-ups and then I did right
(29:34):
arm and then I feel, okay, fine,I did left arm and I could do
muscle up.
So I just keep adding things.
Speaker 1 (29:42):
Yeah, that's cool there's a lot of wild stuff you
can do with calisthenics andgymnastics and stuff where it's
just Olympians make it look sofreaking easy.
But if you're like the averageJoe person, my gosh, anything on
a pull-up bar muscle-ups, evenjust congratulations on doing
muscle-ups.
People work for years to get amuscle-up.
(30:02):
In general, that's awesome andI'm very excited.
I hope you will be in Phillyfor RailsConf.
I hope yes, okay, cool.
Speaker 2 (30:13):
I'm hoping to.
I will be at RubyKaigi.
Cool, I will be Ruby Kaiki andthen I will see how the schedule
work out.
Speaker 1 (30:20):
Cool, cool.
Well, I hope you'll come andthere's an awesome gym in Philly
.
We will definitely go climbingwhen you come to Philly.
Speaker 2 (30:26):
Okay, fingers crossed that you come.
Speaker 1 (30:28):
Yeah, definitely climb together.
Speaker 2 (30:30):
Yes.
Speaker 1 (30:30):
Yeah, that'd be awesome, cool.
Well, is there anything elseyou wanted to talk about,
anything that you're working onthat you didn't mention, or just
want to dive back into Blockers?
Anything before we wrap up,perhaps?
Speaker 2 (30:41):
not these two projects.
Basically captures the recentthree months of my life.
Speaker 1 (30:48):
You got a lot on your plate, but all of it is very
good work that I know a lot ofpeople are very appreciative of.
So thank you on behalf of thepeople.
I at least know that love theLSP and Sorbet and improving
Ruby documentation.
Speaker 2 (31:01):
So thank you for the kind words.
Speaker 1 (31:03):
And thank you for coming on the show.
I really appreciate youspending time to talk about all
the cool stuff you're working on.
Speaker 2 (31:08):
No problem.
Thank you for inviting me.
It's been an honor.
Speaker 1 (31:11):
We'll definitely have you on in another couple of
months, when you're inevitablyon a new project and have a
whole bunch of new cool thingsto talk about.
Speaker 2 (31:18):
Yeah, I can give you a one-year update about Ruby
documentation, for example.
Speaker 1 (31:23):
Always something new, right?
Yes, awesome.
Well, thanks, stan.
Thank you See you guys.
Hello everyone, welcome to another episode of
Code and the Coding Coders whoCode it.
I'm your host, drew Bragg, andI'm joined today by Stan Lo Stan
.
For anyone who's not familiarwith you, would you please
introduce yourself?
Speaker 2 (00:11):
Hello everyone.
My name is Stan.
I'm a developer at Shopify'sRubyDX team.
Dx stands for DeveloperExperience, so I'm working in
the same team with Vinny Stock,who was also a previous guest of
this show, and I moved fromTaiwan to London three years ago
and then, during my work, Ipreviously mostly working on
(00:33):
Ruby SP and I actually alsowrote an RSpec add-on for it,
and then I contributed quite abit to the debug gem, even gave
two talks about it on RubyKaigi.
I'm a maintainer of IRB atRelay and right now I'm focusing
on improving Ruby'sdocumentation from different
fronts.
(00:53):
Oh, by the way, I'm also a newmaintainer of RDoC.
Speaker 1 (00:57):
That's pretty much about it Working on a lot of
stuff.
So the way this is going towork is I'm going to ask Stan
three questions.
I'm going to ask him what he'sworking on, which it sounds like
there's a lot.
I'm going to ask him what kindof blockers he has.
If he doesn't have a currentblocker, he can talk about a
recent blocker he had, how hewent about solving it.
And then the last question iswhat is something cool, new or
(01:17):
interesting that you've recentlylearned, discovered, built?
It doesn't have to be codingrelated, doesn't have to be
coding related.
It can be climbing related, butit can be coding related,
because this is code and thecode encoders, code it and we
talk about code.
So I'm going to shut up now andjust simply ask Stan what are
you working on?
Speaker 2 (01:35):
Right now my main project at Shopify is I'm
working with my teammates EmilySemp and Alex Montelove making
Sorbet the type checker for Ruby, use Prism as its parser, and
to do that I actually startedlearning C++, because that's how
(01:55):
Sorbet is mostly written in,and even a little bit of C,
because we integrate Prism as aC library.
Speaker 1 (01:59):
Interesting.
I did not know that Sorbet wasC++ behind the scenes.
Do you know the history behindthat?
Speaker 2 (02:04):
I did not know that Sorbet was C++ behind the scenes
?
Do you know the history behindthat?
So it's mostly because typechecker needs to be very fast,
and by fast I mean it can kindof index the Shopify monolith in
about a minute, for example.
That's a lot of files and to dothat they need to have good
(02:27):
memory management and everythingthat could be optimized.
So they need to go pretty lowlevel to achieve that
optimization.
Speaker 1 (02:33):
Now I remember when I had, I believe, kevin Newton on
some episodes ago, we kind oftalked about the decision to
move YJIT from C to Rust.
Was it a similar thing, whereit kind of started as a C
project and then they were like,well, c is kind of horrible to
work with because there's a lotgoing on, so let's move to C++,
(02:55):
where we get some help withmemory management, or why was it
C++ and maybe not Rust?
Or why not just straight C?
That I actually don't knowabout.
Speaker 2 (03:07):
But I will say, when Sorbet was created, rust was not
as maybe mature or popular asit is today.
Maybe if we started today, itcould be Rust.
Speaker 1 (03:19):
Same motivation of wanting the speed of a lower
level language and maybe notdoing all of our memory
management ourselves.
Exactly, very cool, very cool.
So you also have worked on theLSP at Shopify, which is, I
think, every Ruby developer'sfavorite tool in the world right
now.
But now you're working onSorbet.
How did you go from the LSP toSorbet?
(03:42):
Is that something where youwent to your manager and said,
hey, I want to try out somethingdifferent?
Did that team say we need moredevelopers who want to come over
?
How is it decided what projectyou work on primarily?
Speaker 2 (03:54):
So the DX team our team will have meetings to talk
about what are the most highimpact tasks, problems we can
solve, and then we createinternal projects based on the
team's discussion, and myprevious two projects were all
(04:14):
RubySP related.
They have set the assumptionson why we need to work on the
project and also what does itfeel like a success when to
finish the project.
So I did that for an entireyear, two different projects,
and then by the end of the firstproject I actually wrote the
(04:34):
Rails SQL blog post aboutco-navigation improvements done
in Rubysp.
We basically do the best as wecan to provide co navigation
features like go to definitioncompletion, for example, without
using any type of information,and that's when we kind of feel
(04:54):
like, okay, most of thelow-hanging fruits in this front
has been picked, and then maybemaking Sorbet using Presen as
its parser will be the next bigthing, because that will space
things up even more for Shopify.
So then I decided to move on tothat project.
Speaker 1 (05:13):
So that's your Shopify life and then your not
Shopify life.
You're kind of focused on theRuby documentation, which is an
honorable effort because we alluse it, we all love it.
But it needs some love, itneeds some updating.
What got you involved in that?
Speaker 2 (05:31):
So similar to many people in our team, we always
feel like we want to improve allthe Ruby tooling, not just
specific aspect of it, andthat's why last year and the
year before I kind of focused ondebug, gem and then IRB,
because first I feel likedebugging can be improved the
(05:52):
most, and then after that I moveon to IRB, because console and
the default repo could be veryimportant as well.
Right now IRB reaches a bit ofalmost feature parity with Pry,
for example.
I just spotted that maybedocumentation is the next thing,
because whenever I go to theofficial Ruby documentation,
(06:16):
which is docsrubylandorg andslash EN, if you read the
English documentation, that'sthe only official English
website and half a year ago it'sterrible.
It's just so hard to look atand then so hard to navigate
into it and that's why nobodyuses it and then nobody even
know that it's the officialdocumentation.
(06:36):
So I just feel like, okay, thisis the next big thing that can
be improved and that will helpevery Ruby developer.
So yeah, that's how it started.
Speaker 1 (06:48):
I agree with you.
It is so important to havereadable documentation.
As someone who hunts down weirdRuby syntax, who has the docs
open a lot, I can confidentlysay they need some love in
updating.
They can be hard to navigate.
You kind of talked about you gofor the low-hanging fruit at
(07:11):
work.
Is it the same with the Rubydocumentation where it's well,
let's just find really easy winsto start updating it?
Or is there a big team behindit?
Was is because it doesn't havemuch investment from the
community.
Speaker 2 (07:40):
And so I would say there's some low hanginghanging
fruits, because it's beenunderinvested for so long.
A lot of work needs multiplesteps to actually take effect to
the end user, and so the firstthing I tried to do is that me
(08:01):
and Colby, creator of RubyAPIorg, after RubyHacky we both became
the maintainer of Rdark, and sowe decided that To get things
starting rolling again, it'sbest to make some very obvious
visual improvements to our users.
(08:22):
So that's why we startedimproving the default theme of
RDoC, which will directly beapplied to the official Ruby
documentation.
It's kind of the first step wewant to focus on this year.
We want to make it morepleasant to read and when more
people use it, people willrealize maybe there are missing
documentation, there are typosmaybe, and then they will want
(08:45):
to get involved and that's whenwe can recruit more contributors
to this area and maybe alsomore maintainers.
Speaker 1 (08:53):
So you're kind of looking to not just get
contributions but also getpeople who are like I am willing
to take on some of themaintainer burden of the Ruby
documentation.
Speaker 2 (09:05):
Yes, the projects I work on moving from debug to IRB
to RDoC right now.
So the project itself touches alot of users.
But when going into IRB, forexample, some but not too many
projects actually use it as aplatform.
(09:26):
The biggest example is Railsuse it as the base of Rails
console.
So it's through that I realizedsometimes working on that
project may not be enough andalso I don't have enough
capacity to do that.
So it's best to find a way tobuild a community around it.
And for IRB it's actually notas easy and also not necessary.
(09:50):
But for documentation it's sucha big effort.
I feel it's something that thisapproach really needs to be
taken seriously than justco-contribution.
Speaker 1 (10:02):
So if you were thinking we want people to come
in first-time contributors, so agood first-time issue or first
contribution for someone, butalso something that isn't I
added a period here somethingthat actually has real impact,
what does that look like to you?
Or what areas do you thinkthose exist the most in?
Speaker 2 (10:23):
So for Ruby, currently we can split it into
two parts.
One part is the contentimprovement and the other part
is the more technical side,mostly centered around RDoC,
because it generates the HTMLfiles, so it controls the
parsing of the source code, itcontrols the theme, how it looks
(10:44):
like, and it controls a lot ofaspects like the SEO of the
final documentation, for example.
So we actually have manycontributors from the community.
They work on front-end, theywork on frontend, they know
frontend better than me.
They contribute small featuresto RDoC's Depot theme and there
(11:08):
are other contributors that aremore interested in parsing.
For example, we got acontribution on replacing RDoC's
Ruby parsers from using Ripperto use Prism, for example.
On the technical aspect, rdochas a lot of places to
contribute to and that's one ofthe things I aim to improve next
(11:30):
year to lay out the componentsand then different things to
improve in each component to letcontributors have a better view
on what part they may beinterested in, and then
hopefully later we can evenprovide a contribution guide for
each component, for example.
Speaker 1 (11:48):
Yeah, that's actually really cool that someone could
contribute to Ruby documentation, but in a very technical way.
It's not the same ascontributing to, maybe, the
Rails documentation, where it'swrite an article on how
ActiveRecordX works.
You can have a big impact onthe Ruby documentation by doing
very technical work.
(12:10):
Is RDoC Ruby or is RDoC anotherone of those?
Contribute to Ruby by writing C?
It's pure Ruby.
Yeah, it's pure Ruby.
That's cool.
That's even better.
Don't have to learn C or workwith C, as it were.
Speaker 2 (12:23):
I have to warn that RDoC is a very, very old project
older than the time I writeRuby, for example so it has some
legacy code you need to firstnavigate through before you can
actually make a contribution.
Speaker 1 (12:39):
I'm very familiar with projects like this.
They yield great talks.
Those can be a lot of fun too,because by needing to navigate
an older code base like that,you can kind of see Ruby's
evolution of its syntax.
And can be a lot of fun,especially if you're doing it
just for fun and it's not likeyour day job and you can just
I'm going to pick this up, I'mgoing to put it down because, ow
, my brain hurts.
(12:59):
That can be a lot of fun andalso might be a good place for
me to find some new game showquestions.
Speaker 2 (13:05):
And also, you know what tool will make it easier to
navigate?
Use Ruby SP with all thenavigation features we just
shipped this year.
Speaker 1 (13:14):
There you go.
You are helping yourself withyour work by doing your work.
Speaker 2 (13:21):
Yeah, that's the good part of working on developer
experience Every tool I improve,I can use it in another project
.
Speaker 1 (13:25):
That's super cool.
That was at RubyConf San Diegoduring community day or hack day
.
I got to work on the LSP alittle bit and it was super cool
to use the LSP to work on theLSP.
It was so Hold on, we've got toload up the LSP so that we can
continue to work on the LSP.
When you're working on a webapplication, you don't get that
(13:48):
kind of immediate feedback onyour stuff, I guess, and it was
pretty funny to be able to dothat.
Speaker 2 (13:54):
Yeah, I guess this is the biggest reason I love
anything that's built fordevelopers.
Speaker 1 (14:00):
And we all benefit from your work too, so thank you
.
So you're working on quite anumber of things, and quite a
number of impactful things.
What kind of blockers do youhave in your work?
Speaker 2 (14:09):
I can give you two blockers, one on the main job
and one on the side questPerfect.
So the main blocker about theSorbet prism work is to have
that translations support errorthe same level of error
tolerance as the original parser, if that makes sense, let me
(14:32):
give you an example.
So when you use Sorbet and youhave a Ruby file that has
certain syntax errors, sorbetcan provide you additional hints
how to fix it, and hopefullywe'll need to achieve the same
hints at the same locations withPrism.
So let me share some backgroundabout this main parser
(14:56):
replacement.
So the main work is thatSolbase current parser generates
.
When you parse Ruby files itgenerates a certain structure of
the parse tree, but whenpresent parses the same file, it
generates different structureof a parse tree.
So currently we write atranslation layer to convert
(15:17):
present structure into SOBASEcurrent process structure.
So then the rest of thepipeline can just not know about
the existence of the presentparser.
So that's what we do.
However, it's not an easy job,but we have mostly completed it.
But in the error cases, becausethere are a few ways you can
(15:42):
write correct Ruby code, thereare infinite ways you can write
incorrect Ruby code.
So right now.
The possibility is infinite.
We need to find out theeffective way to kind of match
that structure in error cases aswell, and we have been trying
(16:02):
different ways, but extremelydifficult.
That's the current blocker onthis project and I don't have
any answer on how to beunblocked.
Speaker 1 (16:12):
Yeah, that's a bit of a crazy one because you're
right, there's so many ways towrite correct Ruby, but there's
so many more to write incorrectand to be able to give that kind
of error feedback.
But the blocker you're havingis that kind of a result of
Prism being more error tolerantbecause it gives you better
feedback.
You need to account for all ofthat feedback where the old
(16:35):
parser just syntax.
We're done.
Speaker 2 (16:38):
Not really, regardless of which two parsers
you are trying to translate, totranslating incorrect files,
past results will always bedifficult because the amount of
cases you need to learn, casesyou need to learn, and also
(17:02):
because we will design goodprocess structure for correct
Ruby code, right, but we may notpay that much attention for the
structure of incorrect Rubycode.
And if you don't do that, thenyou probably don't write
documentation for those cases.
And then so every case, youneed to manually test it and
then document it, even though itmay not even be a design
decision, but you just need tocover everything.
Speaker 1 (17:24):
Everything is an understatement.
That's a lot.
That is a interesting blocker.
I don't envy you for thatblocker.
That is challenging work.
But you said you had two.
So that was the first one, andwhat a good one.
But what is your second blocker?
Speaker 2 (17:40):
So the second blocker is around Ruby documentation.
Again, as I say, documentationrequires efforts from the entire
community.
So first, on this side, I andthe rest of the team need to
find a way to motivate andencourage contributors to come
in and start helping out, forexample.
(18:01):
But on the other hand, wecurrently don't have that many
maintainers to have enoughreviewing capacity to kind of
testing, go through all thecontributions from the community
and a lot of times, as manypeople who contributed to open
source projects may know it'svery frustrating to spend a
(18:21):
weekend on a PR and then nothaving feedback in two months or
even one year.
That's the things we don't wantto see.
But at the same time, if wedon't have contributors, how can
we raise maintainers?
And also, raising maintainersmeans that not only do they need
to have the technical skillsand context about the codebase,
(18:45):
they also need to learn trustfrom the rest of maintenance and
then also the Ruby core in ways, and all of these take times.
I have been trying hard to helpout on both fronts.
That's the current major block,but I will have to say at the
RubyConf this month in Chicagowe have made some progress.
(19:08):
So right now new contributionsare coming in and then we are
talking about possible futuremaintenance candidates and
hopefully next year we will bein very good shape in accepting
community contributions.
And then we can see theimprovements on Ruby's official
websites or Ruby's officialdocumentation.
(19:29):
The improvements pace willaccelerate and then kind of
match people's expectations more.
Speaker 1 (19:38):
That's an interesting little bit of chicken and egg
problem.
Like we want more contributorsbut you don't have a ton of
maintainers to go through allthe contributions.
But in order to get moremaintainers you need
contributors.
But in order to get happycontributors you need the
maintainers.
That's tough, but I guessyou're also a solution to that.
Blocker in a way is hoping thatas much as it does stink to
(20:02):
work on something on a weekendand then have to wait two months
for feedback on it.
Hopefully the folks in the Rubycommunity are understanding of
that bit where it's hey, sorry,we've got a lot going on.
I just had a PR from RailsMerge that I opened two years
ago.
It happens I get it.
It's open source work, totallyunderstand.
(20:22):
Hopefully most peopleunderstand hey, I'm going to do
this work.
It's good work, it'lleventually go in.
Just give it time.
Do you have interestingblockers, sir?
Neither of which I'm jealous of.
Speaker 2 (20:37):
I don't think I've ever been jealous of someone's
blocker though.
Speaker 1 (20:39):
Yeah, that's true, good blockers though.
And so I guess a solution toyour second blocker, in a way,
is if anybody is listening tothe show and is thinking, hey, I
would love to give back to theRuby community in some capacity.
A great way is to reach out toMr Stan Lowe here and get on
board with contributing to RDoCand the Ruby documentation in
(21:02):
whatever capacity you're able to, and when you do that, give
them a degree of patience.
Speaker 2 (21:07):
So that's my call to action for the Ruby community
anyone listening that has thecapacity, get on that, and
speaking of contribution, if youhave limited capacity, there's
actually a certain amount oftypos or grammar errors in this
(21:29):
documentation source, directlyinside the C Ruby itself, that
you can just go find themmanually and fix.
Or I'm actually testing anapproach which is to use LLMs to
(21:52):
help correcting them in batchwith less effort.
So, yeah, you can use whatevertool and, based on my
experiments, llms are very, verygood at fixing those typos and
errors.
It takes me about half hour togo through the same document,
like same files, for exampletracepointrb, inside Ruby to
(22:13):
find all these obvious errorsand fix them and open a PR.
So if that's what you want todo and then become a CRuby
contributor there, you go.
Speaker 1 (22:25):
That's an easy way to get in.
I tried to get in at RubyshotConf Chicago.
While I was working on the gameshow.
I found a bug in Ruby and itwas cool.
I'll be able to get a commitinto CRuby.
This will be great, Turns out.
No, it's so much harder to doit via code.
I'm definitely going to go thetypo route.
That's brilliant.
Speaker 2 (22:45):
I like that, Looking forward to see your PR.
I mean, I don't review thosePRs.
It will be coming to a stoop,but yeah, I'm happy to see you
contribute Still any kind ofcontribution.
Speaker 1 (22:52):
Typos can be super distracting.
When you're reading and you'regetting into something, you see
it and it just takes your brainout of whatever you're learning
and you're like that's a typo.
So they can be very distracting.
Definitely a worthwhile effortto fix typos.
So the last question, myfavorite question, is what is
(23:14):
something cool, new orinteresting that you've recently
learned or discovered or builtor did that you want to share?
Speaker 2 (23:18):
I mentioned that I started working on Sorbate and
then learned C++.
I've never written any C++ or Cor ROS before that project, so
I actually rely heavily on thecursor editor and O1 preview
model, if I'm being veryspecific, and it's just so
(23:42):
amazing how it is able to graspthe context and then also being
super patient on teaching me allthe things I need to know about
C++ in order to make thingscompile and then not stack forth
.
Speaker 1 (24:00):
In case you've never had to work with a language like
C++ before, there's an extrastep that we don't have to do in
Ruby and that is compile yourcode.
And I remember back in highschool working with C and Java.
It took forever even smallprograms, I felt like, and it
was always such ananxiety-inducing.
You hit, run and you're justplease, don't error out, please
don't error out, please don'terror out.
(24:21):
So I am every day very, veryimpressed by all the different
AI tools that come out and howmuch better they get.
I feel like when they first cameout, they were just look at
these AI tools and I was likethey don't actually do that much
for you.
And now they're very impressive.
Andrew Mason was teaching mehow to use copilot edits in VS
(24:43):
Code and how to tell it whatfiles to use in context and what
a difference it makes when youcan say like hey, look at these
files, this is how we write ourcode.
Help me do X and the stuff itcomes up with still not 100%
perfect every time, butdefinitely can help you with the
blank slate problem or justgetting over that hump of hey,
(25:04):
how do I even get started?
Where should I start?
Speaker 2 (25:07):
it's wildly impressive so in my experience
it's basically like a senior C++developers just pair with me
all the time, 24 hours, becausesometimes I work in very weird
hours and then it's always thereand then so patient on
explaining every dumb questionsI have.
Speaker 1 (25:28):
What was the thing that got you to start using
Cursor and what were you usingbefore Cursor?
I guess I don't mean to makethe assumption that you were on
VS Code before, but how did youget to Cursor when I first
learned?
Speaker 2 (25:39):
Ruby, 10 years ago I used Veeam and then NeoVeam and
then two years ago I switched toVS Code.
So you were right, I was usingVS Code.
Speaker 1 (25:49):
It was a pretty good assumption statistically
speaking, but I just want tomake sure.
Speaker 2 (25:56):
I think half of the community uses VS Code,
according to the latest survey.
Yeah, so I was using VS Code,but at the time I used it the
copilot was not very good.
But then we heard Cursor and AIis super good and as a
developer working around DX, Ikind of need to know how good it
is and how in ways we could,for example, provide context
(26:20):
about Ruby better into feedingthese tools.
So, yeah, I gave it a try andthen at the beginning I also
like writing Ruby.
I assume maybe if you writeRails applications, it has
enough database to kind ofprovide you good suggestions.
If you are writing a LSP server, which is very few in the
(26:41):
community, it's not always thatsmart.
It's when I actually work onthis project and learn a new
language that is kind of blownaway by its ability.
Speaker 1 (26:53):
Yeah, that makes a lot of sense that you're working
in an established sort ofmainstream code base but just in
a language or maybe even aframework that you don't
understand, where it kind ofshines.
I have not worked much with C++.
Is there testing in C++ or isit all just hit the compile
button?
If it compiles rock and roll,you're good to go.
Speaker 2 (27:13):
There's definitely testing, but I would say Sorbet
is a very unique project.
It's a type checker, so ittakes another language's file
and then uses different ways toassert the expected result.
So even if I were to write itin Ruby, most of the tests and
(27:36):
expectations exist in a form offiles.
So it's very different from howwe write tests in Rails
applications, for example.
You write actual test cases.
In Sorbet, for example, testsare generated and then they will
just grab the files withcertain names and then run a
(27:56):
result.
Compare you to another filewith certain names.
I'm not sure if that's arepresentative answer that works
.
Speaker 1 (28:05):
Yeah, no, I was just curious because it sprung to
mind as we were sitting heretalking about C++ and I was just
hey, do you test in a languagelike that?
Like I said, I haven't workedreally much with compiled
languages since high school, soit's been too many years.
The other thing that I justwanted to publicly congratulate
you on is your hanging parallelor whatever you call it that you
(28:28):
recently posted on Blue Sky.
That is, as someone who dabblesin climbing and gymnastics,
stuff like that.
That is impressive, sir, ifanyone listening doesn't know
what I'm talking about.
Basically, stan hung from apull-up bar and then got his
whole body parallel to theground while hanging For one
second, which doesn't sound likea long time, but that is an
(28:48):
impressive amount of work to getyour core to be able to do that
.
Maybe if you're used towatching the Olympics gymnastics
, you're like so what Forsomeone who doesn't train as
their day job?
That is really hard work.
So super big congratulations.
Yeah, it's actually calledFront Lever, front Lever Okay, I
don't know names for things.
Speaker 2 (29:09):
Yeah, that's fair.
So I think we climbed togetheronce at last year's UB Conf in
San Diego.
And at that time I just climbed.
And this year, for some reason,I started getting into the
world of calisthenics I hope Ipronounce it right, yeah,
calisthenics.
So it all started from one armpull-ups and then I did right
(29:34):
arm and then I feel, okay, fine,I did left arm and I could do
muscle up.
So I just keep adding things.
Speaker 1 (29:42):
Yeah, that's cool there's a lot of wild stuff you
can do with calisthenics andgymnastics and stuff where it's
just Olympians make it look sofreaking easy.
But if you're like the averageJoe person, my gosh, anything on
a pull-up bar muscle-ups, evenjust congratulations on doing
muscle-ups.
People work for years to get amuscle-up.
(30:02):
In general, that's awesome andI'm very excited.
I hope you will be in Phillyfor RailsConf.
I hope yes, okay, cool.
Speaker 2 (30:13):
I'm hoping to.
I will be at RubyKaigi.
Cool, I will be Ruby Kaiki andthen I will see how the schedule
work out.
Speaker 1 (30:20):
Cool, cool.
Well, I hope you'll come andthere's an awesome gym in Philly
.
We will definitely go climbingwhen you come to Philly.
Speaker 2 (30:26):
Okay, fingers crossed that you come.
Speaker 1 (30:28):
Yeah, definitely climb together.
Speaker 2 (30:30):
Yes.
Speaker 1 (30:30):
Yeah, that'd be awesome, cool.
Well, is there anything elseyou wanted to talk about,
anything that you're working onthat you didn't mention, or just
want to dive back into Blockers?
Anything before we wrap up,perhaps?
Speaker 2 (30:41):
not these two projects.
Basically captures the recentthree months of my life.
Speaker 1 (30:48):
You got a lot on your plate, but all of it is very
good work that I know a lot ofpeople are very appreciative of.
So thank you on behalf of thepeople.
I at least know that love theLSP and Sorbet and improving
Ruby documentation.
Speaker 2 (31:01):
So thank you for the kind words.
Speaker 1 (31:03):
And thank you for coming on the show.
I really appreciate youspending time to talk about all
the cool stuff you're working on.
Speaker 2 (31:08):
No problem.
Thank you for inviting me.
It's been an honor.
Speaker 1 (31:11):
We'll definitely have you on in another couple of
months, when you're inevitablyon a new project and have a
whole bunch of new cool thingsto talk about.
Speaker 2 (31:18):
Yeah, I can give you a one-year update about Ruby
documentation, for example.
Speaker 1 (31:23):
Always something new, right?
Yes, awesome.
Well, thanks, stan.
Thank you See you guys.
Popular Podcasts
24/7 News: The Latest
The latest news in 4 minutes updated every hour, every day.
Therapy Gecko
An unlicensed lizard psychologist travels the universe talking to strangers about absolutely nothing. TO CALL THE GECKO: follow me on https://www.twitch.tv/lyleforever to get a notification for when I am taking calls. I am usually live Mondays, Wednesdays, and Fridays but lately a lot of other times too. I am a gecko.
The Joe Rogan Experience
The official podcast of comedian Joe Rogan.