Hey, welcome back to another episode of the Ruby Grogs podcast. This week,
I'm talking to Mike McQuaid. Mike is one of the maintainers of Homebrew.
If you have a Mac, you know, and if you don't have
a Mac then we'll get into what it is. But yeah, cool stuff
calling in from Scotland. Is that what you said? Yep, Edinburgh,
Scotland. Very cool. I have some Scottish in me. I have a
whole bunch of other European countries in me too. But anyway, do you
want to just jump in and let us know what else people ought to know
about you before we get rolling? Hey, folks, this is Charles Maxwell.
I've been talking to a bunch of people that want to update their resume
and find a better job, and I figure, well, why not just
share my resume? So you if you go to topendevs dot com slash resume,
enter your name and email address, then you get a copy of the
resume that I use, that I've used through freelancing through most of my career,
as I've kind of refined it and tweaked it to get me the jobs
that I want. Like I said, top endevs dot com slash resume.
We'll get you that and you can just kind of use the formatting. It
comes in word and pages formats and you can just fill it in from there.
Sure. So yeah, as Charles as I said, I'm Mike McQuaid.
He said my name perfectly, which is not always something you can rely
on, which is very nice. So I'm currently working on Humbrew in my
you know, volunteer life, spare time sort of stuff. Worked on it
for fifteen years since two thousand and nine I got involved. I think I
was the third person to get a commit bit on the project, and I'm
oh, wow, I'm still standing after that time. And I'm like the
project leader, which basically means I'm sort of an elected like figurehead, slash
tech lead, etc. So yeah, and my kind of outside of my
Homebrew life work wise, I'm working right now start a company last year with
some ex Getthulb people called work Brew, where we're working on commercializing some stuff
around humbrew and basically building the features that kind of small, medium large companies
need that Homebrew does not have so that they can work in the way they
want to work while Homebrew placed nicely with that and then before I was working
here. I worked at GitHub for ten years. I left as like a
principal engineer last year, and I was bounced all over the place there,
but particularly I guess focused on developer experience stuff and open source scratching my own
itches. Basically very cool. Yeah, I've known a few people who've worked
at GitHub. I also remember way back in the day when Chris and Tom
put their heads together and started the thing as kind of a project in a
restaurant or something, And yeah, it's kind of funny to look at where
it all wound up, with Microsoft buying them and everything else. Just kind
of start with the fundamentals here. I did kind of mention that if you
have a Mac, you probably know what Homebrew is, but do you want
to give people a rundown of what it is? Sure? So Homebrew is
a open source package manager for Mac os primarily and also increasingly Linux as well.
Interestingly, oh, really could talk a little bit more about that layer,
because that's sometimes confusing to particularly Mac people. But yeah, so basically,
if you you write brew, which is the kind of shorthand Brew install,
and then pretty much any application you would want, and you can install
that on your Mac, So it's I believe them kind of we have some
degree of evidence that you know, about thirty million people and or bots make
use of Homebrew, and it's yeah, in our opinion, like the best
way of installing open source software your Mac. Well you may not know as
well. With Homebrew, it started off just being like building everything from source
package manager for like open source tools, w get, kurl, whatever,
whereas nowadays you can also install like upstream binaries, so like say like Chrome,
which I'm a diehard Safari guy, so I'm streaming in Chrome today because
I had my usual sadness of learning the website didn't support Safari, so I
find up Chrome, but I install Chrome by just typing brew and still google
Chrome, and then it sticks everything in my applications folder, sets it all
up and all that type of things. And there's a long taiale of like
ecosystems where you can have like brew Bundle is another favorite of mind, where
you can have like declarative ways of telling him Brew what to do and all
this type of stuff. So yeah, that's basically and my my non tech
expansion of rom brew is like a app store for open source in your terminal,
right, Yeah, you just brew install whatever you want, and off
it runs and does its thing. In fact, a lot of tutorials if
you need a particular piece of the puzzle, a lot of the gems and
things that I use in Ruby, it'll it'll basically say, oh, Brew
install your blah blah blah, right, and then and then you can run
from there. So yeah, it's definitely something that I use and I reach
for and I don't even think anymore that, oh gee, somebody actually made
this, right, It's just part of life. So anyway, So yeah,
so I'm kind of curious as we kind of get into this a little
bit, and there's a lot to talk about, right because I do want
to get into work Crew and what that's all about. But before we do
that, for those of us who have used homebrew for a long time and
are excited to see, you know, maybe where it came from and what
all is entailed in it, where did it come from? You said you
weren't in it from necessarily the beginning, but you've got to commitment pretty early.
So yeah, it was sorry there. I think I got involved about
you know, maybe started using it four or five months and started contributing pretty
short after when it was prostrated. It was made in two thousand and nine
by a guy called Max Howell, who was in one that I think he
was working at last FM at the time, the blast from the past that
probably still exists but not as widely used as it once was. So he
had, I have kids younger than Homebrew, I'm sure. Yeah, I
also have because younger than Humbird's. And it's distressing when you meet kids who
are the same age as he Brew and how articulate they are. So he
basically had played around with all the package managers on the Mac at the time.
You know, there was mac Ports and Think and oh yeah, I
remember those, yeah coming what the other one was bats? But yeah,
yeah, mac Ports is probably the dominant one. And he didn't have a
huge amount of like good time using mac Ports, felt that it kind of
did too much and he didn't like the approach, so he built Homebrew,
which was this kind of beer themed package manager. And yeah, and the
other interesting model is still called casks. Yeah, the packages are still called
like formulating casks, and it's still got all the beer themes all over the
place. But one of the interesting things he did as well is it was,
you know, this was I come remember you probably know Chile's actually what
your GitHub open to the public, but certainly this was in two thousand and
nine, so GitHub was like relatively new. I'm pretty sure when humbrew first
got created, the poor request didn't exist yet. But Max from the outset
had decided like, hey, I want to make this thing, but I
can't maintain thousands of packages all by myself, so I'm going to have to
kind of open this up and make it a community effort to do that.
So yeah, so that's basically what happened, and more and more people kind
of particularly in the Ruby community, Like I think the Ruby community was one
of the early adopters of hombrew because humbrew itself was written and still it is
primarily within Ruby, and yeah, basically just it kind of grew, more
people got involved, more people contributed, and then you know, people who
contributed lots and ended up doing a bunch of reviews and stuff like that.
I guess folks like me ended up kind of becoming maintainers, and then the
project's just sort of grown and growing over the time. So yeah, it
went from originally like just Max in two thousand and nine to nowadays, we've
got I think thirty something maintainerous. We've probably had like fifty total old time,
and then we've had like over ten thousand people will contribute to some part
of the project at least once. Very cool. So I have so many
questions. So one of them is is there there are kind of a bunch
of different pieces to this. Right, you've got the command line interface,
and then you've got the hey, go grab the thing, and how do
I know how to build the thing? And how do I know where to
put the thing? And how do we write? And so let's just start
with the command line interface. So what tools did you start out working with?
And has that changed over the last what thirteen fourteen years? Yeah?
Yeah, So humbrew was written originally exclusively in Ruby pretty much, and it's
still primarily Ruby, like the Irony in homebrew Land, compared to maybe other
bits of Ruby where because we're like a CLI, because we're we are installing
a bunch of stuff related to compilers and things, but we can't rely on
the necessarily being there, and we haven't wanted to ship native binaries for the
application itself. When we want to make things faster in Homebrew. Often they
are ported from Ruby to Bash. So an increasing amount of the kind of
very performance intensive bits of Homebrew, like the bits where like you want to
be able to run a command and have a response instantly, or you want
to be able to have a command that you can run every time you open
your shell and it not have too much overhead. So some of that,
more of that stuff is kind of ported to like Bash and like the updaters
in Bash. And because Homebrew installs its own Ruby nowadays, because you know,
we originally used just the whatever rubyship with mac os and that worked all
right for a pretty long time. But I think last year we were speaking
to our kind of Apple contacts and they theoretically deprecated Ruby. I think a
few years ago in the system said hey, can we get a newer one?
And it's still there. It is still there, but it's a two
point six. Yeah, it's not a current version. Yeah, pretty ancient.
And so yeah, so we ended up we were rolling our own for
really old Macwest versions and for Linux anyway. So we're just like, well
we can roll around for everyone now and just make it mandatory. And I
think it's Ruby three point one or two or something like that, uh huh
nowadays, and yeah, and that's a much nicer experience for us and makes
everything a bit faster and snappier and stuff. So yeah, So the main
package manager is all in Ruby, and then we have I guess two main
repositories. So there's like homebrew Brew we would call it, which is like
you do com slasher and brew slash Brew. That's the package manager and that's
that's my personal like favorite happy place to live and I kind of review pretty
much every pr that is in that repo. And then there's like Homebrew Slash
Homebrew Core and so that's like the core formula, like basically everything in there
has to be open source and there's like six thousand packages or whatever there,
and that again is I think one of the reasons why Ruby was such a
good pick originally, like is that the like the the files that kind of
describe how to install something are known as formula. And again going down the
beer theme, and that is like a really nice Ruby DSL that kind of
is I would say fairly if you if you kind of have a basic understanding
of almost like you know, configure, make, make instore, like how
Unix programs are generally built like it's you can read through that, and it's
pretty obvious how to get started. And if you've ever had the misfortune of
having to try and package like RPMs or like dB in packages or whatever,
which are very, very robust, arguably better than Homebrew once they're there,
But like the actual just process of going from nothing to something that works is
fairly time consuming in my experience, whereas in Homebrew you can just you know,
like make a fairly short little thing and then yourself up and running and
storing applications in a pretty quick time. And I think that's why it's grown
and stayed big, because it's quite easy for people to contribute and modify and
change things, and it's just you know, you can do it all on
get help nowadays. Right. So, when I was in college, I
was a systems administrator on mostly red Hat systems, and so I've written some
fugly pass scripts to do all kinds of things, and I've also done RPM
packaging and you know later on I yeah, there are a few things that
I've had to fiddle with and maybe put into a Debian package, and yeah,
that is not a fun process. And then you just kind of have
to put it out there and then pull it in with your package manager or
with some utility that can pull it in and unpack it and do whatever it
does. And oh man, yeah, Homebrew is pretty nice that way.
Also done plenty of stuff with Make, which is it's a powerful utility,
but it's a little arcane sometime, and so yeah, I definitely feel you
there. So yeah, so it's all written in Ruby. Is it pretty
Is it pretty simple? Or are there are a lot of edge cases you
have to handle or is that mostly in the packages or the formula or whatever.
Yeah, a bit of both. Like, I mean, there's I
think with stuff like humbrew is like a really long tail. So I guess
with the stuff that Max created in the first place, you know, I
can't know how many packages he's almost like shipped with to begin with, but
it's one of those things where if you have one hundred packages, everything seems
pretty simple. If you have a thousand, things start to get a bit
more complex, and then right you start getting up to like five six thousand,
it's like it gets really messy. All the weird and wonderful things that
things do. And as a packager of software. You have this kind of
weird decision framework where there's often the way the people who write there the software
originally, I guess we would refer to them as upstream. The way they
want to release their software is not necessarily the way your users want to consume
the software, or the way you want to be keeping it up to date
and stuff. So you're trying to sort of balance these things. And yeah,
I mean the thing I've enjoyed about it personally is like I've always been
a bit of a kind of generalist software ride, so like with Ruby,
particularly when I was just doing a lot more of the packaging stuff than I
do probably today. You know, in a given week, you could be
writing Ruby, c C plus plus Haskell, like having to play around with
like ten to twenty different languages and frameworks and you kind of develop a sense
of how this stuff plays might see together, and what the what the edge
cases are and what you need to watch out for and everything like that.
But yeah, I mean, software is a wily beast, and packaging it's
no less so interesting. So yeah, so what are your dependencies? I
know that you have to have the ex Code build tools installed. Does it
pull in the rest of them for me. Yeah, basically that's on a
map, like that's all you need. You just need to have the excode
like utilities installed. And then even then, like we've we've sort of tried
in the past, like sometimes to make them not required, but it's it's
pretty hard, given like the state of things in Apple Land, to go
completely without that. And you know, every few years Apple introduced some new
requirement which requires using a CLI that only they provide, and there's no open
source version, and we're kind of back to square one there. So yeah,
basically just the Explode Comme online tools are the only dependency. And then
if you're running Homebone Linux, there's a few other bits and pieces there.
But the bigger one I mentioned before like Ruby, like we we build our
own kind of statically compile with Ruby, which you can just use anywhere that's
altered install for you and everything. So I guess some of the something else
that I'm wondering is are you taking advantage of some of the newer features in
Ruby. So for example, you've got wygit right that speeds things up quite
a bit, or the other one is like fiber scheduler and stuff like that
which gives you some level of currency. Are you digging into any of that
or is that kind of upcoming when you get to it. Yeah, so
we've we've played around with like bits and pieces around there. Like so it's
it's funny because humbrew is very much you know that there's been this kind of
meme in the Ruby community for a while that like people get sad that like
Ruby is associated almost entirely with rails most of the time, and like Homebrew
is pretty much as far away from that as you can get, right,
you know, we're not we're not even a web app. We're not attached
to a database like you're running a CLI. So it's funny. I guess
a lot of the places from where the jets come from like never say never,
like it may well make things faster in the future, but right now,
all of the kind of jet, different jets we've tried, and the
different jeits sessions we've tried, Like just the way Homebrew runs, even if
it's doing a relatively complex task like a the run times are relatively short.
Access only sticks around for you know, at most probably a few minutes,
but then a lot of the time it's just around for a second, and
there's new data every time, so you can't necessarily cash things super hard.
And like basically everywhere where humebrew is slow, and like that's the most common
complaint about Homebrew is that Homebrew is slow. That almost everywhere it's slow,
it's slow because of the like io basically like we're either down or something on
the internet, we're write something to your hard drive, we're reading something from
your hard drive, whatever, and we can maybe do a little bit more
paralyzation. But again, like in the past, there's been times where I've
and again some of this may be changing from spinning platters to SSDs or whatever,
there's been times where I've ripped out paralyzed code that we have in Homebrew,
and it's actually dramatically faster running to really than it is parallel. So
yeah, I mean, we we definitely have a decent amount of like profiling
tools like we rely on, but basically everything you would expect and wouldby land
stack, corporal, all these types of things. But yeah, but we
do try and make things as possible we can, and thegits don't seem to
really be helping much for us at the moment, but as I say maybe.
Yeah, So I'm going to move on a little bit too. You
mentioned Homebrew Core, so is that the list of casks in formulae, So
Homebrew Core is the list of formula. So we have Homebrew cosk and Homebrew
Core. So the difference between casks and formula are Like Homebrew cosks used to
be a certain like separate project, and that's the way. That's what you
use for installing like binaries from other people, so like say like Google Chrome
or one password or whatever, like if you're installing that basically if the project
is whether it's a source or not, if the main way that that's delivered
is like a pre compiled thing or like a dot app or DMG or don't
or whatever, then you're installing that with humbrew cost like the essentially to the
user, the interface is more or less the same nowadays, like you type
bruinstall Google Chrome, but brewinstall w GET and it's it looks essentially transparent under
the hoods. But right, yeah, they're they're managed in separate repos Like
this was previously like a requirement due to some open source political nonsense. But
yeah, so everything in Homebrew Core is open source software. And everything,
and Homebrew cost has a much looser requirement basically there and so yeah, they're
managed separately. They have roughly the sammamulate packages, but then like again,
the the DSL that's used are kind of slightly different. And hombrew cost is
a bit more friendly to like propriet your software for guy's whatever. And then
humbrew Core is a bit more friendly to like CLIs and is all open source
software. I gotcha. So yeah, and see I didn't even know you
could install some of those binaries with Homebrew because I always just go to the
website and download it and run the installer and right open the DMG and drag
it to applications or whatever. So that that's really interesting as you get into
some of the open source stuff in particular, how do you know how to
build it? Are you always looking for the make file or is there something
else to it? Or so sometimes there's instructions in like a GitHub repo or
whatever, or sometimes that's kind of you know, it's got to make file,
and sometimes you just kind of try it out and figure it out and
hopefully you can do the right thing. And then two years later the author
pops up and they say, hey, you can building this totally wrong,
and it's like, well, you didn't tell us what to do, dude,
so like that's that's what's going to happen. So yeah, it's it's
always a like there's definitely like a certain amount of kind of trends and traits
of things that behave pretty similarly, and those projects are very nice to deal
with. And then those projects who decide, hey, I'm gonna invent my
own build system because all the other ones saw, and yeah, those are
less fun to deal with. Right. So essentially, if I do a
brew install on something like Google Chrome, it's just gonna pull the binary off
of wherever and it's going to put it wherever it goes and make sure it's
in my path or whatever whatever it has to do in order for me to
be able to run it, Yeah exactly. And then for a formula,
it's going to go through some kind of build process and it sounds like you
don't like auto detect the build script. You go and you look it up
and you add that to the formula and tell it how to build it.
Yeah exactly. So what we try and do like certain bits of what the
in perfection for an end user for the you know, if you're running Brew
and so on your machine, the experience is actually kind of similar because you're
still downloading a binary most of the time. If you're installed hem brew on
like a supported MACROS version, which is one of the last three, and
they're kind of defaulting location right then what it will do is essentially, when
someone submits a formula or an update to a formula, we have our poor
request get hub, our continuous integration will go and like build that, and
then when that works, we then have a process that kind of that build
artifact gets uploaded. We call those like bottles, the binary packages and news
like that. That was my probably favorite contribution to humbrew is doing that just
for the amount of time, it's probably saved the world because before that,
you know, if you wanted to install w get, it would take five
minutes and everyone would essentially spend five minutes with their CPU fans, you know,
in the days before addle Silicon like going at one hundred percent to spit
out essentially the same binary at the end. So yeah, now we kind
of have these binary packages and those are downloaded on your machine and installed and
it's all nice quick and also it's way less error prone because with the compilation
stuff, there's always things where you know, you have some brand them up
utility on your machine and the build script de text that and then blows up
or whatever. So you don't have those same issues with the binaries. And
Hey, there, this is Charles Maxwood. I'm excited because I wanted to
let you know about this thing that I pulled together that I had just I've
been dying to have this for years and I never felt like I could,
and then I just realized that there's no reason why I can't. So I'm
putting together a book club and we're going to read development focused books, career
books, you know, technical books, whatever. The first book that we're
going to do is going to be Clean Architecture by Uncle Bob Martin. If
you're not familiar with clean code or some of the other stuff that Bob has
done, check that out. I've also talked to him on the Clean Coders
podcast, which is on Top End Devs. But yeah, we're going to
get on. He's going to show up to some of our meetings, and
what I'm thinking is we'll probably have like five or six people part of the
conversation along with Bob and I at the same time, and we'll just so
somebody can come on, they can ask their question, and then we'll just
rotate people through, so we'll mute one person, unmute another person when it's
their turn to come on and be part of the discussion. So we'll do
that for like an hour hour and a half. And then the other part
of it that I'm putting together is just kind of a meet and greet gather
area on Gathertown, And so after the meetup and the call, we we'll
do as we'll all go over to gather Town and you can just log in,
walk up to a group and have a conversation, and that way we
can all kind of get to know each other and make friends and get to
know people across the world. One thing that I'm finding is that, yeah,
the meetups are starting to come back, but a lot of people don't
have the opportunity to go to a meetup. And I really want to meet
you guys and talk to you. So we're gonna put all that together.
We'll all be part of that book club. You can go to topendevs dot
com slash book Club to be part of it, and I'm looking forward to
seeing you there. The first book club meeting will be in December, the
beginning of December. We're starting the first week of December, and you'll also
be part of the conversation about which book we do next. I have one
in mind, but I want to see where everybody's at. So there you
go. Right, So it looks at my setup and says, oh,
I know that this bottle's compatible, So I'm just going to give you the
binary instead of making you build it totally, and then if it can't for
whatever reason, then it'll do the build step or the build process. Yeah.
Yeah, and I mean that that essentially should never happen on you know,
support market support right location. But yeah, if you're outside of that,
then it will fall back to kind of building from source and when it
can't do that otherwise. But yeah, but most most things, most of
the time will always be you get like a binder factage for most users.
So right, So just backing up a little bit because you mentioned Homebrew Core
and Homebrew casks is kind of the places where these things live. Is Homebrew
literally going to get hub and cloning it or like, how does it get
that list. Yeah. Originally, well until very recently, yes, we
did that to get hub. Yes. So the original updater for Homebrew was
just it had one repo which was like mxcl which is Max How's GitHub mxcl
slash Homebrew, and that would just be cloned in a directory and when you
ran brew update to like you know, pull the latest packages, that was
just doing a get pull basically. So over time that became more and more
sophisticated. As Homebrew grew, that became slower and slower, Like even the
no up operation of just doing a get fetch on that repo and it's telling
you you don't need anything. That was taken like a couple of seconds.
At the time, I worked at GitHub and I was getting annoyed with how
slow it was, so I actually added a entry to the GitHub api to
specifically to make Homebrews updates faster, and like it ended up being used by
a bunch of other cases and package managers or whatever. Essentially, what you
could do is you could just like pass the the hash that you have I
have used that the the what's called the hp eat tag, So you could
pass the get commit hash as the eat tag and then you would get a
whatever I can vote it is the status code that says not modified essentially,
so it would you do that, and it also wouldn't count against your GitHub
rate limit because that was very heavily cash that operation. So that basically meant
you could get a really really fast response for like gethub repers and we still
rely on that API to this day. And yeah, so until very recently,
like that was still how it was done and we would like fetched off
or whatever, but over time that was getting slower and slower, and also
like GitHub were like, you know, they were pretty nice about it all.
But I think at some point I believe there was like a dedicated bare
metal server that was essentially just twenty four to seven serving Homebrew core to people.
Because also the way that that that reaper had super long history loads or
contributories, right, didn't. I did a lot of like squash and rebasings
like not very kind like history management, and again like thousands of filesand of
folder which we never reknew when humbrew is created is extreme. If you have
very deep histories, get gets very angry and the performance goes to bad places
pretty quick. So yeah, so as of I think it was a year
and a half, maybe two years ago, like someone one of the Humbrew
maintainers kind of started a first attempt at like a little project to see about
Okay, well we can you can effectively turn pretty much all the hungry packages
into like Jason output anyway, and when you're just downloading binary packages, you're
basically just downloading I think, off the Internet and sticking it in like installing
it that way anyway, you don't need all the kind of sophisticated build information
for every package. So yeah, so as of yeah, like about a
year ago, I think we've migrated entirely to what we call our kind of
Jason API, which is downloading just a single Jason file which provides all the
details for those packages, and then you just have that single download. You
don't need to have that Git reports showing your machine anymore, which saves a
bunch of space, and it's like a lot quicker with downloading. And yeah,
and the implementation of that API is another disgusting thing. Where So,
perhaps because I'm Scottish and we are known for such things, or just I
don't know, I don't like pain for things, and in open source projects
I even less so. Our our Jason API is actually on GitHub pages and
it's yeah, so it's all like it's a statically generated API essentially, so
like every fifteen minutes we like regenerate our packages. And what that means is
that it's really really really fast and essentially, you know, nigh infinitely scalable
for GitHub to stick a CDN in front of that and host it that way,
and it's also pretty easy for us to kind of download and debug,
and we're not maintaining some like complex and like you know, when I worked
on the api GitHub, like, maintaining the performance on that thing when you
were at the scales we were out was not an easy feat. And yeah,
and I saw that, I guess working brew and I was like,
nope, I'm gonna If I can make this just entirely static, unauthenticated API,
then let's do that. So that's the route we went down, and
it's been working pretty well for us. That's awesome. I love that.
It also makes me think a little bit that sometimes I might be over complicating
my life but trying to make it work the other way. Right, the
more traditional i'm gonna build, I'm gonna build an endpoint on rails and it's
gonna give all this stuff and it's gonna check all these things instead of just
saying, hey, it doesn't matter if everybody knows this, and it'll be
way faster and it's not that big a file, so yeah, just go
get it. Yeah, it's funny because I had this idea for like over
a decade about like building essentially static APIs where because you know, like static
site. I've used like Jacko and get hub pages for my page for a
long time. I kind of like that sort of static site building model,
and you know, the results are nice and super fast, and it's really
cheap and easy to host and very non error prone. Right once once you've
generated the files, you're like, well nothing can go ron no, right
compared to like maintaining a real SAP. But yeah, so I always kind
of liked the idea of having something a by and I was pleased that I
was actually finely abel to do it because in cases where essentially you want to
deliver the data to absolutely everyone, the data is the same, it's not
like user dependent on whatever, and the data only needs updated like not very
often, like you're not updating like second by second from some debase, but
you're updating it, like, you know, a few times an hour.
Then yeah, like this approach has actually been really quite cool and fun,
and yeah, and encourage others to play it out, although play around with
the approach, and maybe not on gaun pages because get on Ganguru. So
well. I can imagine though, because I'm just thinking through maybe what I
want to do with building an app for the podcast network, right, and
yeah, like ninety nine percent of the stuff that I'm putting out there,
it's going to be the same for everybody, and it's all public and right,
so I don't have to protect it at all, and so yeah,
why not just have a static file out there that it can just go,
Oh, you want the list of podcasts here right Oh you want this podcast
and all of its episodes here right now. Granted, some of the podcasts
have more than five hundred episodes at this point, and so you might get
a little longer a Jason file, but still it's not terribly large, and
you know, you start getting into it really when you start pulling down images
or audio files. But you know, I can put those in as URLs
on the Jason and just make it really wicked fast. And then it's okay.
Now I have restricted access from memberships and stuff like that. That's where
I can, you know, maybe put a check in front of it,
but still then just have them pick up a statically generated thing, because once
you're authenticated, that's all the same too. So yep, killy, I'm
really digging this. Yeah, it's it's been fun. I think, I
don't know that. This is the thing I like about working with open source
and stuff like humbrew is that you know, you get. I guess the
thing I've learned in my career is the most interesting projects are the ones often
worth any sort of constraints, right, Like the projects would like, you
know, take as long as you want, you have as many people as
you want, do it whatever you want, in whatever language you want.
Like they're they're often like maybe I'm just a masacus, but I find them
often like less fun, whereas the fun thing was saying our humbrew as well,
it's like you're building humbrews that you're it's that well we we have Like
I guess the way I describe Humbrew's financial situation is like not enough to pay
anyone, but too much for stickers. Right, so you have like this
like middle ground of money, and as a result, like it's this tricky
thing of like, well, I don't really want to put us in a
situation where we're paying vast hosting bills, so let's try and figure out a
way of doing this for free essentially, but it has to be able to
scale to like, you know, millions and not tens of millions of people
like using this thing. So yeah, so like that's been a fun kind
of comparison compared to as I say, you know, like get up dates,
where you're scaling to many more people than that, but you also have,
particularly post Microft acquisition, like many more resources you disposal in order to
achieve those scales, and you're not worrying quite as much about the bottom line
as you along. Yeah. Yeah. The other thing that I can I
just went through my head was and this isn't Jason at XML but RSS feeds
right Oh yeah, yeah, yep. So yeah, all right, so
we've kind of talked through how the repository works. And let's say that I
decided I wanted to be build the cl lie and it was moderately complex.
Are there are there things that you recommend to me as a Ruby developer as
places to get started. I mean, the funny thing is, I wasn't
you know, I realized this. Maybe I don't know, a controversial take
for the podcast, but like I mean, nowadays, I probably wouldn't necessarily
reach for Ruby for a CLI, like it's it's okay for like doing doing
you know, I still think it's great for doing web apps. But like
you know, I've I've been building like a new CLI for some of the
stuff we've been doing with work Brew, and like Go feels like a more
I was basically weighing up between like Go, Rust and Swift basically as like
the Swift for that Well, yeah, I didn't tank Swift at the end
for various reasons, but you know, I ended up going with Go,
which I it's I don't know, like for me, Go is just it's
good at what it does. It's such a boring language. I don't have
any fun when I'm writing Go. But you can ship a single static language.
Yeah, and it's super fast and for CLI's like it's like the responsiveness
is really great. I think I think that's the thing that maybe I'm just
burned for like fifteen years of working in a Ruby Cli. But like there's
a certain amount of people will complain about the slowness that it's like literally even
like a Ruby interpreter spinning up and saying hello world is like unacceptably slow to
some people, right, And at that level, I can't really do anything
to make it it faster. But I guess if you, if you are
going down the route of almost like really wanting to get into make it some
sort of Ruby cli or whatever, I guess I would just say, like,
you know, the beauty of Ruby is that you can start with like
a single script, right. You can just have a script stick the shebang
at the top, like the for those who don't know, that's the thing
where it has like exclamation mark ash like user bin anyway, like user bin
room or whatever, and then you can just start writing Ruby code straight away,
right, And like that's that's how I think is the best way to
maybe get started with like CLIs or whatever. It's just like rough and almost
like reaching for some option parsing framework or whatever. No, just go and
just start writing some Ruby and just read the rg V, which is the
array of like the arguments you pass into the script, and like just read
that yourself and just you know, don't don't go too fast, too quickly,
and you'll probably have like a good time. Because again, like when
you're CLIs if you wanted to distribute them to other people, like if they
you know, if you start lying on loads of other gems and stuff,
then it becomes like a little bit more of a headache to kind of distribute
and use these things and keep them up to date and whatever. So like,
yeah, I think the beauty of Ruby is like Ruby has like a
pretty decent broad standard library you could do a lot with like a single script,
and even like an old version of Ruby, like the ones that ship
with like nec o s like there's still you know, it's still a powerful,
like pleasant language to work in. So yeah, very cool. So
yeah, so is there anything new coming in Homebrew or yeah, I mean
we're always working on It's funny because people quite people ask periodically about like the
roadmap for Homebrew and because we're essentially i mean maybe except for me, now
like essentially almost everyone is like a volunteer. The room map for Hebrew is
kind of like, well, let's see what people want to work whatever people
want to work on, right, And it's like the product management on Homebrew
kind of looks more like nerds attempting to nerd snipe other maintainers into solving problems
that it does like you know, building a team and assigning them a six
month project or whatever. So yeah, I mean, I think like a
big thing is like performance, Like we're continually trying to kind of eke out
better performance where we can. And then yeah, and I guess like I'm
looking at it from the kind of work Brew end as well of being like,
okay, well, so if me and a team of people are actually
able to work on Homebrew full time or like spend like a decent amount of
our time putting into hombrew like one of the really big impactful things in Homebrew,
that kind of might people might look at and say, that's just impossible
that we could do if we have like a paid team of people who are
working on this stuff full time. And I don't want to, you know,
I don't want to be too spoilery with that, but yeah, there's
definitely there's definitely some stuff we're exploring where if we see that there's interest and
we can kind of pull it off, I think people will really say wow
about but in the short to medium time, I think there's more along the
lines of yeah, just like making Homebrew faster, more secure, and making
the contribution process better and just trying to do everything we do right now like
better basically, Like I mean, I'm a big fanic GitHub and on Homebrew
of like when I wasn't get helped, that was like reading really really heavily
into automation. So again, like a lot of what we're trying to do
on Homebrew sometimes is like we've only got thirty people maintaining the project. But
yeah, the throughput of like prs we have and it's fairly ridiculous, and
we just try and have so much automation, leaning more and more and more
heavily into that. And anytime you know, I catch people doing things that
I'm like a bot could do this, then it's like, right, I
try and write some code and get the humans down the human things and save
the boat work for the bots. So I was going to ask about work
Brew. I'm gonna ask about in a second, but you did mention maintainers,
and so if somebody is like, oh, I've got a great idea
for Homebrew, or you know, I use this all the time, and
I'd like to contribute back to it, right, Is there a good way
for people to get started with contributing? Yea, so Homebrew the best way
to get started is like a contribution section on the read me of the homebrew
brew. So if you go there then you'll or if you even just search
for like contributing to homebrew, like the result by results a pretty decent.
I would say our docs are probably like on the better end for like contribution,
our tooling is probably pretty good. But like I would say, like
it's a really easy project to get started with, and we we really try
to kind of cheerlead the people who want to get involved with the project.
So like, if you're in any doubt, just try something and we'll help
you out, and you can mention me by my GitHub handle or whatever if
you say that it's your first PR and you're struggling, and I'll try and
do what I can to help you and stuff like that. It's a yeah,
as I say, I think it's a really good project to kind of
get started with, but as you know, for some of us at least,
it's also can be fairly addictive at times, so be wary from that
perspective as well. Yeah, all right, So the other question I have
then is, yeah, do you want to talk about work Brew like what
it is and your head and with that, yeah, So I mean,
as I mentioned earlier with like Homebrew, like, I've been working on humbrew
for fifteen years and for you know, probably ten of those years, there's
been people who have been encouraging me at various points to oh, you know,
you should make a company doing stuff around humbrew, and I have been
historically kind of down on this idea or fairly cynical, but do when I
mean not going to name any names, but you know, there's been various
companies who kind of have done open source stuff and then you know they can
plain down the line when everyone uses their software, but they're not making enough
money or whatever it may be. And right, I guess to me it's
like open source itself is not a business model. And also like I you
know, I kept like you mentioned earlier, like you've got you know,
kids younger than Homebrew and stuff like, I also feel like who was kind
of my first child, and I feel quite precious of it, and I
wouldn't want to you know, like destroy it or whatever. So it's yeah,
it took a while for me to get to a place that I was
like, yeah, actually, it feels like a few things have come together.
So one is like Homebrew feels I mean even with the Roman stuff,
Like if we'd have this conversation a year ago or two years ago, I
probably would have said, like more stuff on the horizon, But it feels
like fairly close to kind of feature complete at this point without almost like a
big injection of kind of effort and stuff. But that was one part.
The other part is that we've got I won't go into all the boring details
of like open source governance, but you know, but we have an open
collective. We have a like a leadership committee, we have elections every year,
We have like ways of getting involved with the project beyond just like corn
dogs and stuff like that. We have money that we're using to like provide
stipends to some maintainers and pay for them to kind of come and meet each
other in person and stuff. So the project feels like it's in a really
good, mature place, and it's also in a place where no one party
could ever kind of completely take over oh Brew, even if they wanted to
and so yeah, so, And it's also in the backdrop of this,
I guess, like, you know, I left GitHub last year and were
sort of looking for a new challenge and something new. And you know,
again, over the last ten years, there's been various times where companies come
and say, hey, we'd like, you know, Homebrew to do this
or that or whatever. And essentially what a lot of humbrew features come down
to is, like, do the volunteers who are mainly working in their spare
time want to build and support this right and for a lot of like big
enterprise stuff at dinner Charles, if you ever had the misfortune of reading through
like a samle speck or something like that before. But you know, once
once you get into this like big enterprise tech, like, it's often not
very fun and it's not what we want to spend their evenings and weekends doing.
And I previously worked like before my Homebrew days, and like an open
source company back when I was a KDE contributor and this company consulting company,
and they hired more KD contributors than anyone else, and I worked and I
thought, sweet, I'm going to be able to work on open source mods
at the time, but I learned pretty quickly that their open source projects were
actually not super fun because they were basically stuff that people would play a consulting
company to go and like, hey, like we've got this stuff which we
can't get anyone to do for fun, so will you do this for money?
And then they're like okay, well fine. So with work Brew,
I kind of see it as being a similar thing where what we're trying to
do is, you know, there's a lot of talk about sustainability and open
source and stuff right now, and I guess that's on my mind. I
worked on the original team of people who built get up Sponsors and have helped
kind of Humbrew have that open collective, and to me, like this is
the next almost like step in the evolution of like what sustainability could look like
for Humbrew is having a commercial entity where we're trying to kind of make a
sustainable like commercial antitee who has an interest in making money in the Humber ecosystem,
but not charging money directly for Humber itself. Humber itself will is and
will always remain like free of charge, but we're going to make Humbrew better
by making work grew better and be providing services to companies in the humbre ecosystem
through our expertise and by building stuff that tightly integrates with Humbury. So essentially,
the version of work Brew that I like run on my local machine today
looks and behaves almost exactly the same as Homebrew, except it's got a little
coffee cup instead of a beer emerge. But it's you know, it's running
in a different way. It's running in a more isolated like fashion and multi
user fashion. Right, it's like reporting back to do fleet management, so
someone could upgrade like if I've got critical vulnerabilities remotely and so that people can
see kind of oh like you've you haven't updated in six months and we've got
some problems with that or whatever it may be. So yeah, So essentially
that's what we've tried to do. We're trying to build something that provides a
better experience for using home brew at work, but for most hobbyists, I
mean, we very much have the goal that if you in five or ten
years and we're successful, even if you've never heard of work Brew, even
if you never interact with work Brew, you will look at essentially roundabout now
as being an inflection point where Homebrew gets really really good in the next five
or ten years and it gets noticeably better for everyone using it because we're able
to kind of get involved and improve the sustainability of the project through the commercialization
of this part of the ecosystem. That's cool if people want to know a
little bit more about what's going on with that, like do you have a
mailing list or something, or yeah, so update somehow. Yeah, the
best way of like getting in touch with us, We've got a contact form
on our website. If you got to work through dot Com slash contact,
then you can like send us all your message and then we can go and
get in touch and we'll kind of send you emails and stuff like that.
And you can also see if you go to work with dot Com our demo
of what we have in private beta right now, which is essentially like fleet
management for Homebrew and kind of integrated with the MDM tools, so that basically
like mac Adminson primarily and you know, security professional developer experience where us can
basically get a nicer experience of using Homebrew at work. So yeah, so
we're recruiting like design partners for that right now, which essentially means like people
who will give us lots of feedback while we make the beta kind of more
to their requirements. So again, if you're interested in that, best way
is reaching out through the contact form, and if you have any thoughts equally
as well, if it's easier, if you're one of these people who's get
scooped by contact forms, you can send me an email. My email address
is pretty easily findable on the internet, so if you do that, or
it's just micut workbow dot com or at brew dot sh if you want my
open source email, awesome, all right, Well, if people want to
connect with you on some other level, where do they find you on the
internet. So I'm still I'm basically read only mainly on Twitter nowadays. I'm
Mike McQuaid on there, but the best place probably is I'm Mike mccaid at
massive on dot social on like masted on nowadays, or if you just find
my website at Mike mcad dot com. That's basically got you know my I
try and kind of put if I write blog posts or like do talks,
and all my contact information is there and stuff as well. So yeah,
and you'd be surprised how a few people actually just email me to say hi
or share their opinions. So feel free to do that for almost anything,
except for saying my herd Bruce broken, please fix it? In which case,
okay, right, all right, good deal. Well I'm gonna go
ahead and roll us into the picks here. Have you ever wished that you
had a group of people that were just as passionate about writing code as you
are? I know I did. I did that for most of my career.
I'd go to the meetups, I try and create other opportunities, and
it was just really hard, right the meetups. I got some of that,
but they were only like once or twice a month, and it was
just really hard to find that group of people that I connected with and really
wanted to, you know, talk about code a lot, right, I
mean, I love writing code. I think it's the best. And so
I've decided to create this community and create a worldwide community that we can all
jump in and do it. So we're going to have two workshops every week.
One of those or two of those every month are going to be Q
and A calls right where you can get on you can ask me or me
and another expert questions. The rest of them are going to be focused on
different aspects of career or or things like that. Right, So it'll go
anywhere from like deployments and containers all the way up to managing your four oh
one K and negotiating your benefits package. Well, we'll cover all of it,
okay. And then we're also going to have meetups every month for your
particular technology area. So we have shows about JavaScript, React, angular view
and so on. We're gonna have meetups for all of those things. I'm
going to revive the freelancer show. We'll have one about that, right,
so you can get started freelancing or continue freelancing if that's where you're at.
And I'm working on finding authors who can actually do weekly video tutorials on some
thing for ten minutes. This related again to those technology areas so that you
can stay current keep growing. So if you're interested, go to topendevs dot
com slash sign up and you can get in right now for thirty nine dollars.
When we're done, that price is going to go up to seventy five
dollars, and the thirty nine dollars price gets you access to two calls per
week. The the full price at one hundred and fifty dollars, which is
going to be seventy five dollars over the next few weeks. That price is
going to get you access to all of the calls and all of the tutorials
and everything else that we put out from top Endevs, along with member pricing
for our remote conferences that are coming up next year. So go check it
out topendevs dot com, slash sign up and I we usually have the host
go first, so I'll go first. One of the first picks I have.
I always pick a board game when I when I do my picks,
and so I'm going to pick a board game called fire Tower. And basically
it's a it was a relatively simple game. Let me look it up on
board game geep real quick while I tell you how it's played. But essentially,
all of the players have fire towers in the corners of the board,
and so what you're trying to do is you're trying to earn everybody else's tower
down before the fire gets to and burns your tower down. And so you
can play two to four players. We played it with four people. It
was a lot of fun board game Geek rates at a one point seven to
seven. I tell people that it two is kind of a reasonably complicated game.
It's complicated to be fun, but not so complicated that it's hard to
pick up. And so, yeah, this is right in there at that
level playing time, it says fifteen to thirty minutes. I think we played
it forty five, but it was our first time. Yeah, ten plus
player or ten plus on age. I honestly think my eight year old could
play this game rights. It's pretty simple, and after she played it once
or twice, she'd probably get most of the strategies figured out. Right,
don't have the wind blowed toward your tower, put down the fire tokens in
a way that gets it closer to the other people's towers, I mean,
right anyway. So so I'm gonna go ahead and pick that it was a
super fun game. Really enjoyed it. One other one that I'm gonna pick
is we were talking about some of the install stuff and Daniel Keho, who's
used to be in the Ruby community way back in the day. He has
a website Mac dot install Dot Guide, and it walks through how to install
like Ruby and a bunch of other stuff, and it pretty heavily refers people
to homebrew. So anyway, I'm going to refer to that just as a
resource that people can go check out. And then I had something else and
I'm just kind of blinking on it. Anyway. The where I talked to
Daniel most recently was when I picked up the Railscomposer dot com domain from him,
and so I'm working on that. You can actually watch me build rails
composed and all of the different rails engines that I plan on putting together for
that on the Rails Clips video series. So just go to topendevs dot com
you can find it. I think I also own railsclips dot com and I
think that goes to the right place, so go check that out. But
anyway, yeah, good stuff, Mike. What do you want to pick
on the show. Yeah, okay, I guess I will do three little
picks. So one would be I'm reading a book right now by a guy
called Alistair Reynolds, and he's a science fiction author. He's written a lot
kind of space opera stuff. I've written read all of his books that he's
ever written so far, and he released a new one a couple of months
ago, which on eighty eight percent of the way through called Machine Vendetta that
you Penny Arcade talked about it, and you probably don't want to jump straight
into Machine Vendetta. This has been a couple of books of preceding it in
the series. You want to deal with the discussion of hyper pigs in the
first paragraph, which may throw you off. My second recommendation would be a
band you may or may not be into their vibe. They're called Ale Storm
like a storm of Beer, and I guess you can see there's a theme
going on. They are Scottish pirates metal band. I'm seeing them live next
Sunday in Scotland, but they play internationally. My kids really like a song
from their latest album called Pirate Party because it has a moment with a man
drinking from a shoe, which is apparently very funny when you're four and six
years old. But generally I would not recommend most of their songs to children,
and as they are very heavily expleted written in some of them. But
you, you know whatever, they may work for you or not. And
my final recommendation, I guess on the theme of open source maintenance in particular
is therapy. I've been doing therapy intermittally since twenty two and I've something I've
found tremendously helpful personally with all sorts of things in work, personal life,
my relationships with my friend's family, kids, wife, and even on occasion
I have sessions where I talk about particularly difficult person I'm dealing with open source
land in a given therapy session. So if you're interested, I would highly
recommend it. And I've written a blog person on my website of like a
step by step guide if that's your way of doing things, of like how
to find a therapist. So if you're interested and that's useful to you,
please consider doing that. Oh man, given the last few months that I've
had, I might need that anyway. What was the name of the band
again? And if you can put a link into the comments, that'd be
great. Yeah, I will drop a link into the band let me see.
But yeah, we'll go ahead and wrap up here. One other thing
I was just going to put out there, This is the thing I forgot,
is that my contract work has slowed down a bit. So if you're
looking I'm either looking for a full time job or a contract perfer contract.
But you know, if you've got an interesting set of problems and you're going
to pay me well to fix them, then I am happy to consider full
time work. You can just email me Chuck at topendevth dot com. All
right, thanks for coming, Mike, This was really really interesting. Thanks
for having me, Chuck, and have a good rest today everyone. Yeah
you too, max out everybody.