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.