Hey, folks, Welcome back to another episode of the Ruby Rogues podcast. This week, I'm your host, Charles max Wood, and we are talking to Mike McQuaid.
Mike, you came on before.
We talked about homebrew and building Homebrew and work brew.
And all the stuff you were doing at the time.
Is there anything else you want people to know about by way of introduction or yeah?
Not really all the same old stuff, Like I'm not kind of doing as much stuff on work brew nowadays.
I'm doing even more stuff on Homebrew nowadays. So yeah, all good stuff. Nothing really has changed.
Good deal.
I use work or not work Brew, I use Homebrew all the time. So yeah, glad, pretty handy. It runs on Linux too, I think I think I wound up using it there somewhere.
Yeah, yeah, it runs on Linux, and I guess because it's Linux. But we've still got a little a few tweaks there as well, on like WSL on Windows as well, so I've ended up playing wrong with it all my Windows gaming machine, which until recently been unsullied by Homebrew.
Un slowly. I love it. Yeah. We we talked quite a.
Bit about Homebrew and how it works last time, and I thought it'd be interesting because I find myself sometimes fiddling with like writing scripts or things like that on my on my machine and then thinking, you know, it wouldn't be too bad to kind of parlay this or these set the scripts into like a CLI. And so I was just curious, I don't even know where to
start with that. But since you've kind of built a CLI that a lot of people use, I know you had other contributors, but yeah, let's say that I'm sitting on some stuff that I think belongs in the CLI.
Where would you even start with something like that? Yeah?
I think that's it's really good question because I think the a lot of this depends on I guess, like a lot of stuff in tech, right is like what does your scaling story look like? Right to be one of those boring people of like if it's just something that you're writing.
For yourself to run it once and throw it away.
Then you know, thinking about like the language you use, like you just want to reach for whatever is the most familiar to you, or I guess in personally nowadays, like whatever you think chat chpt can one shot a reasonable approximation of.
What you want it to do, and then you can tweak it before you run it.
But yeah, so like that way more than I care to admit.
Oh for sure.
I mean it's great because I feel like there's a lot of stuff around that where there's like scripts that previously we just wouldn't have written. And then now just being like, hey, I want to pull the state from the getab api and previously being like, oh, that's possible, but I really want to spend like two hours on this, and then it's not like well, I'll spend twenty seconds asking chat CHPT and look at the output and if it's wrong and then it doesn't matter. But yeah, so
I guess that's the first thing. Is like, so for me personally, like I tend to reach for like the smallest, dirtiest, filthiest scripts for Bash because I'm pretty comfortable in Bash.
There's Bash has like a huge amount of gotchas though, so as soon as it becomes even slightly load bearing, even for you, you probably want to go to like a no offense Bash authors like a real language, and at that point, you know, stuff's pretty interchangeable, like if we're on a Ruby podcast, So like Ruby is really good for like yeah, standalone single file cli script. That's what I would tend to kind of go for straight away. If you're a Python person. Python's pretty good for that
type of stuff as well. I think, like, you know, if people don't have familiarity with those, I'd be surprised if they listen to a Brewery podcast. But then, you know, I'm sure you can probably do equivalent stuff in C sharp and various.
Other right more obscure languages.
But like, I guess that's where I would tend to go next is just be almost like, okay, how can I put in a single script and you can do some kind of neat stuff with Most people are familiar with Bungler for installing dependencies, but then most people are also like, okay, like bundler, I have to do like bundling stoll and bundle exec and.
All this type of stuff.
But actually you can do some cool stuff with bundler where you can actually define a gem file inside the script itself, so the first thing it does is shouts fall its dependencies installs them all, so that that can be again quite a nice way of extending some little basic scripts.
Yeah, I just want to back up on that for a minute, because I ran into that somewhere I can't remember where, but yeah, it's just its own little syntax in there, isn't it.
What exactly do you have to do in order to.
Yeah, I can't remember the exact syntax with top my head, but yeah, basically, like, I mean, that's the nice thing about the state of Bundler and Ruby in twenty twenty five is if you're installing an even vaguely modern Ruby, it's going to come with a vaguely modern Ruby gems and Bundler out of the box, and then everything essentially you can do through the CLI you can also do
through the Rubia guys instead. And that means that essentially every input that you would previously have poss as a parameter, you can poss in as a string or like your gem file instead of reading it from disc you can like have that be like a here doc in your Ruby script or whatever it might be.
Yeah, Like so that's a nice way of getting there.
So like, that's what I will tend to do is have like a little bit at the top of maybe one of my scripts that's like, hey, if I need this particular gem, then install this gem at the first time it's run, and then I don't need to like carry along the script and a gem file and whatever. I can just run it wherever I need to and however I need to.
Yeah, I did find it. You require a bundler inline and then you do gem file do and then you basically put all your gem file stuff in there.
So you do your source which is probably RubyGems.
Dot org, and then you gem whatever and yeah, you just use your the domain specific language for the butler for the gem file. Yeah, and off it goes.
It's pretty cool.
So then when your script's getting a little bit more I guess load bearing, as we were saying as well, like that might be when you want to be like, hey, I want to have some like options parsing, and like the most basic way of doing that is just you know, you've got the rg V like array and you can go and.
Say, okay, what's the first parameter, second parameter. But if you want to handle flags.
And switches and being passed in different orders, there's like the Ruby again part of the standard library. There's the Ruby kind of option parser library, which is pretty good, pretty easy to use. If you're still in bashland, there's like sort of a Bash equivalent, but in my mind, even by the time I start getting towards like multiple argument parsing, it's like, that's again a nice sign that I probably want to go into Ruby, and yeah, use
that kind of richer library. And there's also various gems that provide different dsls for whatever your preferences are in that area.
Yeah, that makes sense. I know a lot of people also use Optimist. You used to be called trollo.
Yep.
If you're been around for a while, and it's like optimists, it's the same thing.
Yeah, so do you have this reference.
It's funny because I tend to.
I tend to like not I tend to use just the most basic, like I'm going to pull stuff out of rg V until it hurts. I think it's also because I've been around in Homebrew and Ruby and whatever, like long enough it's like I'm aware of all of the kind of educases that you get there, and like if you delete a random part of r V, or if you jup it, or if you check for inclusion, like what.
The various gotches are.
So like I wouldn't necessarily recommend other people do what I do, but yeah, but I guess I don't have a particular library of that I prefer for this stuff and Homebrew because for a very long time, Homebrew kind of couldn't really by design use any Ruby libraries without fully.
Vendoring them all, which was a big pain for us.
Like Homebrew basically built its own argument parser and stuff like that. Even today, like Homebrew were a little bit I wouldn't say suspicious of other libraries, but it's like the we care. I guess this is a nice segue to the next thing you might start caring about with the CLI, which is like Homebrew nowadays, we really care about like the.
Run time and almost like how long is.
It going to take to essentially, you know, do the thing that you want it to do, So like how long how long until you can print a Hello World once you have all your libraries loaded and everything like that.
And I think that's the type of thing where like if you have a script that you run once a month and it takes thirty seconds to run, you probably don't care if it takes five seconds or thirty seconds or a minute, right like it's but if you have a script that you're running in your shell, prompts say, and then your shell's not going to be print your shell prompts, not getting it printed until the script completes.
All of a sudden, you maybe don't want to require that library.
You may be want to do it by hand so that you can just boost it, or you may well be getting to the wards the point which Homebrew is.
Not quite able to do.
But some the other CLIs I've built more recently, I guess, like at work Brew and at GitHub or whatever, it's like, okay, you maybe want to reach for another language at this point. So Ruby is really good language. There's been a lot of performance optimization work that's gone into Ruby in the last five or ten years, but a lot of that comes from the shopifys and the gethubs, who are not focused on how can I make a CLI run as
fast as I possibly can? But they're focused on like, how can I have a long lived Ruby process realistically running probably rails of Sinatra or whatever, which can serve as many requests.
As possible as quickly as possible.
Right, So that has more performance implications around like memory management and garbage collection and JITs and stuff like that, and things which rewards the longer execution of the application, which is the exact opposite of what CLI does. Unfortunately, some things like Ruber Coop have kind of got around that by having I forget what they call it, but there's basically a mode when you can essentially have Ruber cops sitting in the background and you end up sending
requests to an already running process. I guess we could maybe a take that approach with Homebrew one day, but we've not yet. So instead we're generally concerned about like, how can you how can you shave that time down? How can you require as little as possible and push
some logic into maybe Bash in home Brew's case. But when you're writing like a prophecy, a lie and that's you know, that looks like maybe nowadays probably the best choices would be something like gut rust or go, depending on your preferences.
Like go, for example, is.
If you're used to Ruby, it's a very sad language I think to write because it's you cannot be.
Expressive, IM go right now?
So yeah, so how have your experience has been with that?
About like going from the delights of ruby Land to go land with the stuff?
Yeah?
Yeah, I don't love it. I mean I'm just barely getting into it. They use it at work, so yeah, back end engineer encompasses Ruby and go. Yeah, and mostly I get away with not doing a lot of Go, but yeah, they kind of expect and need you to.
So yep, yeah, it's you. I feel like there's there's definitely been several schools of languages where the underlying methodology is like stop people from doing stupid stuff, and Ruby feels like it's almost as far in the other extreme as you can do, where it's like you can I mean, I'm sure you've reviewed some absolutely heenous Ruby code of the years where people have metaprogramming to an absurd yeah Goldberg level where it's impossible to figure out what's going on,
but that also allows you to build incredible the powerful rails and all of this stuff, right and go.
I'm sure you have the same Charles. I just end up feeling like.
You know, this like twenty line switch statement could be one line of coding Ruby, but you know you don't let me have the you know, you've taken away the keys to this particular car, So I guess I have to write the twenty line switch tament.
Yeah, I just have to say, I mean to a certain extent like control flow and things like that.
It's all the same.
You know, there's some funky stuff with like very variable assignment and functions and things like that, But yeah, it doesn't light up my soul like ruthe does.
Yeah.
Yeah, Like Go feels in many ways to me like a sort of much less verbost Java. Yeah, Like I wrote a bunch of Java back in the day when it was peak Java enterprise beans, and you know all this like accessive boiler plate, and there's a lot less at the boiler plate and Go.
But it still feels like this non zero amounts. But yeah, so I'd say.
I would still consider reaching for Go for a CLI if you really care about that.
Like execution performance.
So for example, I guess when I was at work group previously, I was working on the CLI there, which wrapped around Homebrew Cli.
So we wanted to provide as little overhead as possible.
And the amount of stuff you can do in zero point one of a second on modern hardware and Go compared to Ruby is like fairly spectacular. Like in Ruby you're really trying to make sure you avoid like any IO or significant significant computation or anything like that.
Ross Road just just.
Because of the virtues of it being like a natively compiled language.
You can just do an awful lot of stuff much faster.
And that the multi threatened story as well, is like because it's not the global interprets of walk or a come that's the Ruby name, but whatever the Ruby equipment is. Yeah, you can you can afford to just leading into the concurrency a lot harder.
Yeah, that makes sense.
So let's say that I want to build a CLI and I'm trying to think of like a super fun example. Let let's say that I'm gonna, you know, I'm gonna get an open ai ap apike and I'm gonna you know, I'm gonna make it talk to whatever, right, so you know, maybe it'll talk to multiple services there. Right, So I'm doing stuff maybe with the podcasts, which is kind of what I'm imagining, right, So I hand.
Off my.
Audio or video to whisper and it bought I being I got a transcript, right, and then maybe I hand the transcript off to d LLM and it does some stuff. A lot of this stuff I mean you would put on the back of like a rails app or anything else too, right, But you know, I want a command line interface just to make it super easy for me to kind of navigate through some of this stuff.
Where would you recommend I start?
Yeah, I mean, like for me with stuff like that tend to in some ways, that's a kind of general question. We like, how do you bolde software right? And I'm sure everyone has different ways, but like the way I've always liked to do it is essentially just try and write the Well, I'll give my pre ai answer first. My pre aions is essentially just right the filthiest, hockiest code, assuming that no one will ever read it, to just get the core thing done.
So I guess in your case, it's like, okay, I want I.
Would write a script and I would point there. I'm not going to do any argument.
If I'm just going to assume an argument has been passed. I'm going to pull out the first argument. I'm gonna get the file, maybe the MP three file or whatever from the podcast on disc. I'm then going to load that into memory and then going to pass that off to Opening.
Eyes Transcription API.
I'm then going to pull down the result of that as like Jason or whatever. Then I'm going to immediately get that not store anywhere, stick that inter opreenning guys like im API do something with that, bring that down and then print the output right and essentially build it in such a way that there's no air handling. If anything is in any way not the happy path, then it will fail with a completely incomprehensible whatever message.
Right.
So, like generally that's the way I like to feel out how to do things initially, And like I think sometimes with like CLIs and stuff like that, it can be tempting to be like, oh, I'm going to add the options first, you know, because that's if you're almost like thinking from like top to bottom. That might be how you would think about it. But actually, like that's not really Probably the thing you cared the most about. You're trying to figure out is this thing even viable
or useful or whatever. And every minute you spend fiddling with options is a minute you're not figuring that.
Out right, right, not doing the quarteine that makes sense?
And then so one thing that I'm looking at is so then do you just build the CLI around it so that you can say transcribe file nan yeah or exportant.
So I again with this type of stuff, like I tend to go for like, keep everything in one file like until it starts falling over, right. And I would again to start with not even necessarily use any methods until I'm thinking about making things kind of dry and you know, I'm having to call the same thing multiple times or whatever. Right, So I just would tend to do that until it feels like it's getting too much.
I don't know what that is, whether that's you know, a couple hundred lines, five hundred lines, one thousand lines whatever, right, and then start splitting up. You said, if you had commands like say you're passing like a transcribed command to do this, or like a read out loud command or you know, start a chat command or whatever, then that might be when I'm like, okay, well, logically there's like three different things this is doing. Probably the code between them is not actually that similar.
So maybe these could all split out into.
Separate files that are stored a bit separately and included separately and whatever. And again that's one of the pros and cons of kind of Ruby and Go and stuff like that, because in Ruby, okay, you've got those different files, but you've now once you've slit into multi files like if someone else is like, oh cool scripts, how can I use it? Then it goes from being like here's literally like the copy and pasted script contents to being like, you need to clone this repo.
And here's how you want to ask this.
Yeah exactly, So like okay, you could but make it a GEM and then they could gem install it. But like I'm showing my Homebrew maintainer bias here, but I've I personally I really like Ruby jams and equivalent to other languages. For like I want to library I'm writing Ruby. I want to library for Ruby. Right, I kind of resent it when I'm like, I want to install a
tool that just happens to be written Ruby. I don't actually care what language this tool is written in, right, And I have to use MPM with JAM or pip whatever to install some run to cli. Like for me, I would always either reach for Homebrew or if it's just something my mate wrote, ideally, my mate just like sends me the script and I have like a dumping ground repo and I just like copying paste that file in's by report and then I can run it or modify it as I choose in future.
Right, So that was that Yeah, you're you're talking around one of the things that I was going to ask, right, Because if it's just one file, it's like, Okay, stick this in your path, make it executable, bam, you're done, right, But if it's multiple files, yeah, I was trying to figure out, Okay, how do you package that?
And I guess, yeah, you could use some thing like Homebrew or Yeah.
I agree with you on the I mean, if it's a Ruby specific tool like Rake, I don't really have a problem with it being in Ruby gems. But yeah, like the I've used other CLIs. I think it's like the Heroku CLI or the Stripe cl I can't remember, but one or two of those. It was like, yeah, I had to go NPM install it, and I'm going, yeah, but this is not a code tool, yep. And that's yeah,
I agree with you there. It's like, no, this this belongs in Homebrew or apt or YOUM or you know whatever whatever your package manager is for your operating system, where it's going to pull it in and say, hey, this is a utility you're going to use for other things. Right, it's an application essentially that runs on top of your OS.
I just yah, Ruby podcast, it feels like a safe space to admit this.
But yeah, like I my one is like NPM, where it's like I ideally I don't have no Jetz on my system at any given time, right, So like when when something sayss like, oh, the way to do this next step like step one NPM stall x and so well, actually there was a step zero which was installed no.
J I and given this thing.
That you're asking me to do is nothing to do the JavaScript, Like, I don't see why I have to do that, right, So often I'm like, Okay, I then go looking and I'm.
Like, oh, is this is this already in Homebrew?
And if not, maybe I package it and homebrew my own benefit and other people in future or whatever.
But yeah, I've always felt that that's that.
Yeah, the kind of I think that's a You've brought up a bigger question there about almost like distribution, and I think that's that's a bit more kind of messy and complicated because it ends up being like, well, what is.
The distribution method?
And Homebrew somewhat infamously, I think it might be one of the first, maybe even the first to the whole like cold to bash install the script that everyone is much the rides, but like, you know what, if you're installing something exactly, it works. But also like if you're trying to install something that's kind of like non trivial, like homebrew that involves cloning a pot and you know, again, it's like the MPAM install. Like we could say, okay, well step one get cloned, and so well I don't
have GET on my machine. It's like, okay, well you need to still get. How do I do that? Well it's you whoops.
Yeah, I guess that's my issue, right is I generally have noted NPM on my machine. Right I'm working in rails, you know, I need some kind of JavaScript run time, and so it's like, Okay, this feels weird, but I'll do it. But yeah, if it's a PIP install because I I never touched Python, or you know, if if it requires Go or something like that.
Now these days I'm working on Go.
But yeah, it's like, why do I have to install a programming language in order to get my tool when it doesn't really have anything to do with the programming language.
And so yeah, just getting into you know that step.
I guess some of these come like self packaged or when you do the install, then it'll you know, behind the scenes, it'll install either a standalone version of the laneguage or give you some way of building it on your machine, or sometimes it's just an executable that's pre built that you know, it has reasonable assumptions about what's already there. Yep, and so so that works. But yeah,
so let's say that I am building a CLI. I write it in Ruby, you know, Yeah, I mean I can tell my friend to go get clone it, right if they're a programmer, and you know, and then it's like, okay, here's the command to run it. But yeah, let's say that it's something that's getting wider adoption and it needs that distribution right where it's.
Hey, you know you're going to go run this on your own machine.
Right, Maybe it's a fancy CLI that cleans up large files on my hard drive or something like that. Right, it's some other utility that does some of these other things. You know, it's helpful, and I don't need a UI for it, or at least not a complicated UI, big graphical UI.
Yeah, how do I begin to package that up?
Yeah?
So again, probably unsurprisingly, my natural response to that is like Homebrew is pretty good, yeah, distributing software, right, So with Homebrew you can kind of stick it in a repo and then call like Brew, create dashtash, Ruby, point that at the repo and then humbrew will try its best to figure things out. But then you know, if it can't, you can fiddle with that and hombur can
help you with that. And you know, if this is a thing that's pretty widespread use and you're packaging someone else's software or whatever, then you could submit it to the main repository and ChIL It'll be accepted fairly quickly and then everyone can benefit that. If not, we have this thing called called taps, which are like third party repositories. Basically that you can run a command Brew tap new, which basically will create a new.
Tap for you.
You can then push that up to get hub as a repo, and we spit out some nice CI workflows so you can use those free public repo actions minutes to put them to use, and then you could use that as your distribution method if you want instead, and then that could be a nice way of you know, regardless of what language you.
Write it in, if you're doing Ruby or Python.
Or Go or whatever. Then you can distribute your software that way pretty easily.
So if there's any kind of setup or build step or anything like that, is there some version of like an install script or something that it runs or yeah.
Yeah, So there's like in Homebrew's Ruby formula, which is kind of like our DSL for like building and installing software. Basically there's yeah, there's like an install method and basically you can much like a normal Ruby you can run a bunch of system commands in there. Like we try and do a reasonable guess of like, hey, if it's a Ruby project, you probably want to run like bundle install and then you know, stick a Ruby file in a bin directory somewhere and that probably gets you most
of the way there. But yeah, but it's basically just like little nice dsls that can kind of help you
get that software onto your machine. And it's I think one of the nice things about Homebrew is it's definitely of most of the packaging systems I've ever intacted with, and from what I hear from people, it's one of the easiest to just get started with like an existing piece of software, because essentially you're just like, Okay, run some commands which you can try yourself in Bash and then move stuff from one place or another, and then that's you.
So I mean, in the case of Ruby, Homebrew already runs Ruby. But let's say that I reach for something like Go or Rust or maybe I'm using Python, right, and so I can't assume that the person whose machine is going to get installed on has you know, the language or language tools that I need in order to build and run it. How do you manage that kind of a thing.
Yeah, so in Homebrew, that's we just have like a long line again with DSL.
Depends on where you can basically say, okay, I need Ruby or this particular version of Ruby or whatever it may be.
Where against all that globally?
Yeah, yeah, so it install that, but Homebrew keeps track of Okay, did did you ask me to install Let's just say, say we have or openly night transcription thing, call it transcribey or whatever, right, and you might install it with Bruins School transcribe, So that would install Ruby automatically because that's what you said. But then in a year you're like, ah, you know, Ruby sucks or whatever.
I'm going to rewrite this and go and then you switch your.
Packaging to Go, then Homebrew knows when you ran Bruins School Truscribbe you weren't saying, hey, can I have Ruby and transcribing. You were just I just care about truanscriby. I don't care what trubscribey is written in.
Right, So then if it.
Changes in the future to Go, then Homebrew that knows like, oh well you never asked for Ruby.
We don't need Ruby anymore.
Let's give it a Ruby, right, And again the fun thing to Go as an example is like, and this is where it gets slightly different. I won't go into the details unless you're really interested of like if you're you're building it yourself versus if Homebrew builds it for you.
But if humbrew builds it for you, then the nice thing about Go is because Go spits out binaries, then you don't even need to install GO on your system, right, you can probably use the finery that we have built for you, so then you can get it Ruby.
You don't need Go.
We need to instill GO when we're building it for you in our service, But on your system you don't need GO unless you're building a right from source as we would.
Say, right, similar with Rust, Yeah, exactly.
And it seems like with the approach that we're taking with Ruby or Python or something that's not compiled that way, or Node as another example, right, if it's running on any of those, the install node or install Python or install Ruby approach works fine on Linux or Mac or in the u SSL, yeah, WSL, whatever it is. I am not a Windows I help my wife with Windows, but she's not using the Linux emulator. So but yeah,
so that works fine there. And then if you need to package it up for something like Windows, then then you're looking at another tool that's going to essentially package your language. Right, It's going to put your Ruby VM in the execute the ball so that you can run.
Yeah, so that's when it starts to get a bit more messy, and different languages are optimized for that. So again, like going right back to our original, like I'm writing a CLI, so I think like one of the first questions I would probably have is like, what are the chances are that you're going to want to ship this to Windows users?
Right?
And if unless the chance is definitely not, then Ruby and Python and even more so things like Bash are you know, very easy to get started across when there's sorry across Linux and mac Os from the outset. But then when you have like a Windows story, that's when
it starts to get a bit more messy. Like Windows ADS. Again, like plenty of PACKGEP managers and stuff like that, but your average Windows user is not going to be familiar with those, and even a lot of Windows developers don't necessarily use like package management as widespread as it is
in the Linux and mac Os worlds. So that's when I would say, like the story that Go for example can do for you is I'm less clued up on Rust in this way, So I might excuse me any Rustians who are listening that I might not know quite as much about what Ross people are, but certainly I know. With Go, the nice thing is you can just build a single binary which you can then have run on a Windows machine and that will work as expected.
Right.
But the other nice thing with Go is it's the cross compilation story is very easily is very easy. So even if you only have access to a Mac machine, you can build the binary on your Mac for all mac OS versions essentially and Linux and Windows. And if you don't have access to those operating systems. You can have a reasonable degree of confidence that, unless you're doing kind of wackys specific stuff, that that binary will just
run fine on all three HOSS and like that. That's a pretty appealing thing if you're building a CLI that you want to be used cross platform.
Yeah, that makes sense. I'm a little curious getting into running it on Mac versus Linux? Like are it seems like for the most part things just generally work the same way. Are there meaningful differences that you need to be aware of in certain cases?
Yes?
I think most of the time you don't need to think too hard about things, and I think it's it's often relatively obvious when you're sort of starting to get a little bit more detailed. So, for example, one difference would be the you know, we're gonna really nerd out some nice os well like high level ors internals here.
But you know, like mac os and Linux run different kernels, right, there's the Linux kernel and the mac os Darwin kerdile and then there's the stuff in user space as well, so like because yeah, like as you mentioned, like macOS came from like a BSD kernel land like most of the user space applications or BSD and on Linux, most of the user space applications.
Might be g do once.
And Apple won't do so because of GPLC three, which is a whole other, long and boring conversation. But yeah, So basically, like if you're calling out to various say like even Gret, right, Gret has arguments that will work on maquest and they will not work on Linux in the same way, and vice versa. So you might if you're shelling out to Gret, you might need to have
like conditional logic based on the OS you're on. Or alternatively, instead of shelling out to Gret, you just say, Okay, I'm gonna instead like get all the lines and I'm going to iterate off the lines in Ruby and do
things that way too. So I think with with like writing Ruby itself, like Ruby and Python are both generally written in such a way that like pretty much everything you would ever try and do is going to be cross platformed by default, Right, it's just various little gotcha's like shelling out or again, I can't remember this is still the case in twenty twenty five, I'm pretty sure it is. But like, by default, the next generally ships with a Letussure ship with a case sensitive file system
and Macwest ships with a case insensitive file system. So if you're doing all your development on Mac and you have like some file that you read in from your repository or whatever, and it's uppercase a you know, Anti TERB with an opper case versus antique with a lyric ASA that will watch just final mac os if you're inconsistent.
Between the repo data on disc and how you've written in your source codes.
But then on the next that my plot right, So like these are types of little things that you need to care about when you're doing cross platform development.
Gotcha.
So yeah, I'm just trying to think through the rest of it. I'm imagining that. Yeah, if I split things up into files, what it's going to do is it's going to put all of my files into one place, put the executable in the path somewhere, and then the executable is going to be aware of where the things are and just have that in the load path essentially exactly exactly.
Now, with testing.
Are there specific things that you do when you test them or do you just kind of test the internal logic and assume that your flags and stuff work.
Yeah, so that's a good question as well, because I think, particularly we've never really written a CLI before, you would probably think, particularly once you get to like the multiple files level of like, Okay, I'm going to write a bunch of unit tests for the internals and make sure that they work.
My experience as a you know, longtime.
CLIR is that like, actually, that is going to cause you a lot of pain unless you have at least some tests that are actually shelling out and running the script externally, right And we I guess relatively recently in Humbrew, which in my mind is probably like ten years ago, but that's recent as far as I'm conturned.
Yeah, So we used to have.
A lot of tests that would just you know, unit tests, and then we would just find that like really core functionality would break because all the internals, all the internal APIs we're working, you know, it's it's the tailors all the time with like unit test versus integration test, right of, like you can have all of your internal APIs working perfectly and are beautifully tested, but then when you fit
them all together, things explode. So as a result, like I've always found with CLIs in particular, like really taking that sort of outside in testing approach is really nice to ensure that you're like, okay, so say again, we're
talking about this opening CLI type thing. Like if I was writing a CI pipeline to test that, I would probably give giob actions my like either my or test open ei key, and I would have it in CI like actually trying to run a transcribe command on maybe like a single word or some very short amount of input data and actually making sure that as close to a real use of that application is actually being tested and working as expected, because all the kind of clever,
like all the cleverer unit tests you might have will just otherwise fall over when you need them the most.
Yeah, I like it makes sense. I'm gonna oh, go ahead.
I was just gonna say, so another thing you might find, I guess as I've been talking about, like CLI performance, because it's sorts in front of my mind with this stuff.
So there's a guy.
Who's written loads of really helpful little CLIs and rust I forget his name off the top of my head, but we can find him Google him later or whatever. So he's got a really nice tool he's built called hyper Fine, which is a CLI benchmarking tool. Basically it does a bunch of other things, but that's what I've
found it most useful for. So what that does is it takes this sort of outside and approach and you can say like, hey, I want you to run this command this many times and then tell me like what the performance characteristics are, or I want you to run this command and this command and tell me the difference
between the two. So quite often when I'm doing like Homebrew performance work, the way I will measure the performance differences is like that command could include like checking out a brunch, or you can you should specify that as
like preparatory command or whatever. So I'll say, okay, check out this brunch, run this Homebrew command, then check out this brunch, run this homboric command, and then it just has a nice little display of almost like well, when you run this command, it's one point four times faster on average, and that varies by like two percent like across the iterations, and it will I think everyone's at ten times by default, but you can you could say run this a thousand times or two times or whatever,
and there's like as you might expect for kind of a beautiful like proper cli.
Nerd cli like this.
You know, there's like so many different options to twiddle every possible knob to get it to work exactly how you want it to. But yeah, but if you're ever in a world where you're like I really care about the perform Morman's implications of my cli, like that is the best tool I've ever used and works basically exactly how i want it to because it does that inside out testing right of like actually running the actual process and then measuring the actual time that like it runs forth.
So big shout out the hyper fine.
Yeah, the I found it on GitHub.
It's David Peter and or shark dp is his gethub handle, And yeah, yeah, looks like a cool tool because.
I wanted to switch gears a little bit.
Yeah please, So I was.
I wound up on your blog when I was getting ready for the episode, and you have an article on here and we've wound up talking about AI, and it seems like it's still the hot topic. It's funny because over the last i don't know, three four or five months,
I've really started to use AI quite a bit. Sometimes I use it essentially to write most of the code, and then I have people, you know, get concern learned about whether AI is going to take people's jobs and things like that, which you address in your article here it says open source maintainers thrive in the LM era. You know, you address some of that, and you talk about how people are using lms and things like that. I'm just wondering, like, what's your experience using LLLM tools
like Cursor or Copilot. And then the other question I have is, and you kind of address it here, is is there any hope for the people that are freaked out that AI is going to take their programming job?
Yeah, so I guess I'll make sure I get to both of those. But yeah, I guess the experience wise, I've been probably using some sorts of tools and some cost of capacity since the very early days. So like back when Copilot was still an internal alpha, I get help based on I.
Think GPT too to start with.
Yeah, and opening I had publicly not really done anything except released a bunch of papers. Yeah, Like I was asked to test it internally essentially, and like I was known for being the type of person who was good if you wanted honest opinions of the things. I was testing because regardless of the political consequences, if you asked me to test some thing and I thought it was all trash, try to be nice about it, but like I would not tell you that it was great. I
would tell you that it was not great. But yeah, So I remember trying this and being like this will because I'm sure people it's almost hard to even remember. But like if you put yourself back in whatever this was like twenty twenty one or something like that, Like you know, if someone had described what you're able to do now with Copola or Cursor and they said I built a thing that does this, you would be like your eyes would roll out your head and then you'd
be like okay, like yeah, whatever. Like I've seen a lot of autocomplete, like right, it always sucks. It just gets in the way. It's annoying, it's not useful. Like I write Ruby now, the auto complaint in Ruby sucks. I don't really care and I don't really miss it
anymore because I've got used to it and whatever. This is just yeah, nothing that I care about, right, and I try to and like my almost immediate reaction was like even in when it was way more limited, was like, wow, this is this is not like radically transformative yet, this is not incredibly workflow changing yet, but this is really good.
And this is a lot better than I expected.
And ironically, you could build a pretty damn good autocomplete without any specific knowledge of Ruby as a language, but just using this kind of LM technology. And I said to the team, I was like, yeah, I assumed this would be complete garbage and it's actually good, well done, Like can I keep using this please? So yeah, So I guess I went from that to use and copolitive.
I just want to chime in that lines up with my early experience with a lot of it, where it was it was a little beyond autocomplete, and it didn't always give me what I wanted, Like sometimes it was like you are assuming that I am doing something wildly drastically different from what I'm doing, but it was it was right often enough to where it was like, Okay, I definitely want this turned on.
And I think that's the thing like in the early days particularly, and I think maybe some people who tried stuff out too early of over index on this. I think it was very personal in terms of like what what's the hit rate? Because I mean, I find this with self engineers in general. Right, is there some selfware engineers I know who will completely genuinely, without any sense of irony, will express but this only solves the customer problem ninety nine percent at the time. Therefore it's pointless
one percent of the time. Why would you ever do that?
And so well, actually, for most people, if this makes things one hundred times faster ninety nine percent at the time, which I'm not saying AI does, but like in some declative software cases, things do, that's probably an enormous amount of business value for a lot of people, right, Right, But there's we have and I don't think it necessarily a bad thing, but we tend to have a streak as a you know, we're literally the people of zeros and ones, right, So it's like we want things to
be perfect, and when things are perfect, it's easy to kind of fawardto the like, well one did I bother, like, you know, what's the point? Yeah, And I definitely think there's only lms, like the only copilot, it's like the autocompletion was you know, if that's wrong fifty.
Percent of the time.
There's a lot of people who just find it really really annoying, Whereas I'm the type.
Of person, yeah, but it sped me way up.
Exactly, Like Whereas I think I'm lazy enough that I'm like if fifty percent of the time I can just like I'm a reasonably fast type or I was never one of those like hyper fast. I've switched to the Vorac because it gets me an extra ten per second whatever, like VIM keyboard warrior types. So for me, like I'm like, oh, yeah, you know, like half as much typing some of the time is well worth it for me, right, and I can I feel able.
To ignore the visual noise of it always.
Trying to prompt me to do the wrong thing, right, And some people wait that and I guess it right, But yeah, I guess I would say if you're one of those people who I hated that in you know, maybe even six to twelve months ago, like you should check back in because things are changing, yeah very fast.
Right.
Yeah, So kind of getting into the question that I'm asking, I'm enjoying this, right, I'm not saying you didn't get to the point, of course. What I'm saying is so like this morning, right or last night, I think it was last night I started it, and then this morning I finished it. But you know, I'm expanding my podcast hosting system which also does courses in summits and coaching and podcasts and screencasts, right, because that's all stuff I want to offer off of the back of the podcasts.
Right.
I was like, okay, well, I've got this multi tenant setup going, and so I need people to be able to sign up, right and actually pay me to use the system. And so I said, hey, I need a sign up for him. And I mean, it wrote all the views and rails, It wrote all the management and the admin system, It wrote you know, and and it basically worked. I mean I had to tweak a couple of things because you know, it was like, okay, you you know, you.
Got this wrong.
And then when I asked to do something else, it changed it back and I had to go in and say, no, actually you did it wrong the first time.
But I mean it it.
Would have taken me a day or so to figure out, you know, to actually build it out on my own, right, go in and put everything together. It's all pretty basic stuff, but it I mean, it just wrote it in like twenty minutes, right, and then and then the tweaking took me probably another forty five minutes, and so I can see people looking.
At it and going, this thing is going to take my job.
Yeah, And I understand why people think that, and I guess, like, to me, it would be when someone with your level of experience, Charles, is able to do that and there is zero tweaking, and like, I've done this one hundred times in the last two weeks and never any point if I had to change a single character like that would be when I would be more concerned about being like, well, you know, maybe I still think the job of being a software engineer wouldn't go away in that case, because
I think we are even outside of the programming. Right, my was cooking some sweet potato in the air fryer yesterday, right, and my wife and I both use Chattypata, and I transcribed at using voice, and she heard the way in which I speak to CHATCHYPT and the amount of context I gave it about like here's some facts about my particular sweet potato and how I like it, here's some facts about my air fryer and whatever.
And she was like, wow, like you you said a lot of.
Stuff there, whereas I would just be like cook sweet potato in air fryer, right, and the proplet she would get back would be pretty poor, And the prop that I get back is amazing, Right.
So I guess some.
People talk about like prompt engineering or context engineering or whatever, but like, I think there's more to it than that, and I think there's a reason why the experts in prompt engineering or context engineering don't just happen to be
like international tennis players or philosophers or whatever. Like there's mostly software engineers, or at least software adjacent people, because like, this is still talking to computers, and computers still like to be talked to in a like LM's like to be talked to in a different way to you know, your CPU.
But it's still sort of an art and a craft in that way.
And like I can definitely imagine almost the worst case scenario of when you're gonna be writing a lot less code by hand than you ever were before, and for some people that really bums them out and freaks them out.
But I still think that job of like I take customer requirements and turn them into software, that's still a job, right, And that's still a hard job, and it's still a job that someone like yourself, with a lot of experience you are able to work with LMS dramatically more effectively than a random person who started coding two months ago.
Right, Yeah, I agree.
There are a couple of things you kind of talked through that I want to touch on. I mean, one of them is, yeah, you figure out what essentially what context you have to give it, right, so you give it all of the information it needs so it can break it down and go okay that this is this is what I'm working with, and then yeah, it'll give
you a much better response. One other thing that I found that just kind of comes with experience with the LLMS is that and this came up today, like I forgot to tell it I'm not using device on my Rails app, and so it actually said right because I told it. I was like, you need to send an email confirmation when people sign up for the system, right, not just a welcome email, because I need to confirm
that their email works. And so it turned around and it said I see that you're using device confirmable and I immediately had to get in and stop it and say I am not using device right then, and then it did the right thing, and so.
You know, I had to remember that.
And so some of that with the prompt engineering, Yeah, you figure out what context it needs in order to make the right decision, and then you give it to it. And a lot of it, too, is just being thorough right so that it doesn't make any assumptions. I know, we're kind of answerpromorphizing the LM and it's just a predictive language model, but you know, yeah, it doesn't make
any assumptions on what you want. And so yeah, some of it's going to just boil down to, yeah, I'm the human that's giving it a proper prompt that gives me better outputs. But the other thing is is that, yeah, I still find that I have to tweak it, or at least I have to verify it right. Even if I didn't have to touch it, I have to verify
that it does the thing right. I have to spin up my app and go and click through it or write or if it's a CLI, you know, I have to run it a couple of different ways to make sure that it's still doing what I want.
And so there's that too.
And then the last thing that I'm going to just point out is like, I'm not seeing companies laying people off saying, well, you know, we're using the LLMS to enhance the capabilities of our programmers and so we don't need half of them anymore.
We're not seeing yet.
What we're seeing is we're seeing companies go, we can get ten times the work done or you know, five times the work done, are double the work done by having the engineers that we have use the tools.
And I think that just accelerates.
And I think any company that's shortsighted enough to turn around and go, we're going to lay off half of our technical workforce, their competitors are going to come in and eat them alive.
Yeah.
Yeah, I think that's some people that speculate that's the case, some companies hint towards that being the case, But I don't think it's. I think what you are seeing, and again, I think if we're talking about things that you can be freaked out about, is like, there's definitely been a big drop in hiring for juniors, right, like this measurable
decrease in junior engineering positions. And I think there is this outstanding question of like, again, you and I have touched upon this already right, Like I say in that post. One of the reasons why I talk about like why I think open source maintainers are well clout for they for the llm ROR. Right, is that conversation you mentioned before, if you were talking about building something an open source project, you could have equally been describing almost identically, some.
Contributor you've never worked with before.
Right, It's like, oh, well, you know what, I opened an issue and then overnight some random person I never met before appeared.
They made a pr like it was mostly.
All right, I had to make some tweaks, and then I emerged it right like, And I actually think the trust and verification process looks very similar, right for someone like yourself with a lot of experience, someone like me with a lot of experience, particularly if you have a lot of experience with one code base you've worked with for a long period of time, like you're able to provide probably very in depth review of a relatively large amount of code in a very short amount of time
in a way that makes these tools valuable to you. Right if you were you were unable to do that either because you lack the experience, you lack the contact with the codebase, you lack the program and buility yourself.
Then all of a sudden you get end up in.
This pre care position where it's like, okay, either I go one hundred miles an hour and like if this stuff breaks, I wonder how to fix it, and I won't know even really how to describe to the LLM, like what's gone wrong beyond just copy pasting error messages and when when that fails, like I'm just shit out lunk, right, or I slow down and I say, okay, I just I'm.
Going to learn software the same way everyone learns software before LMS.
Right, And then the people that I have to kind of have a bit of the FOMO or even potentially my management chain being like, hey, all the seniors are like twenty five or fifty percent more productive, now why aren't you? And it's I'm glad I'm not responsible for social engineering or whatever, because like I think that's a really hard question of like what are we going to do as an industry, because we can't just say we don't hire more juniors anymore, because that's not going to work.
But at the same time, I don't think we have a really good answer for like what the juniors should definitely.
Do to scale up, right.
Like, Yeah, it's hard, Yeah, I like, I like, I completely agree with you. I think kind of reading between the lines on your blog post, it seems like part of the answer is having juniors or people who are at that level doing open source with you, right, because then it's not you don't have your boss or your company or the deadlines or things like that where people
are going, why are you taking so long? And then the other thing is is that if you do take the extra minute, even if you're still generating the code with AI, to then ask the LM okay, explain to me.
What you just did.
Yep, right, you can start to get context for what it did and why it did it. Now it may not be giving you the best practice, but it's giving you at least some context for what it's working with, and in some cases it is.
Going to be best practice or at least common practice.
So and you're seeing that even with LMS now right now, like the kind of study mode and chat GPT and things like that, where I've played with that a little bit myself when I've been kind of trying to learn new things that I don't want to overlylean on the LM, and you know, it's kind of trying to do a bit of Socratic method stuff and all this sort of thing.
But even with I think it's a great point for the open source where you know, there's a bunch of talented homer maintainers I know who are in some cases haven't had a tech job yet, are still in college or relatively recently out of college, and like their code reviewabilities for typical expectations of like a new engineer are like completely off the charts. Like some of them are dramatically better at code review than I am, having done it, you know, probably ten times as.
Long as they have, but they've had a lot of experience doing this.
And I think that might be part of the junior story is that I think we cycle we sort of had a little bit of an attitude I think for a while, at least in some cultures of companies I've seen where it's like, well, okay, we'll get everyone to view a bit of code, but really like the more senior people are going to be more responsible for doing the more in depth hardcore code review of like gnarly stuff, right, And that might be the culture that needs to change,
but we're actually like, okay, rather than saying to the junior is like, hey, you just spend ninety five percent of your sign coding. Don't worry about this code review stuff too much. You'll figure it out as you go along. Maybe we need to flip around and be like, actually, you should spend ninety five percent of your time doing code review and don't worry about this coding stuff too much.
If you read enough of other people's code, you're going to figure that out, right, And maybe that's where we go. And certainly that that would be an attitude that would make you more qualified with working with LMS better for sure.
Right, you brought up code reviews and that that kind of reminded me of another thing, since we're talking about AI and things like that. So yesterday I put in a PR at work, and I asked some folks to review it, and I got on this morning and it still hadn't been reviewed. Whenever people get in and they see the message, I'm sure it'll get done. Anyway, When I checked it, get how asked me if I wanted Copilot to review my PR?
So, how do you feel about that?
Yeah, I've actually at work brew and now at Homebrew and some companies have done contracting with have enabled. In fact, I don't know if I've done this on humbrew actually, but basically, whenever I can, I enable enable copilot review of prs by default, and I think good. It's sort of so it has definitely caught a bunch of stuff
that humans have not caught on my prs. Again, the false positive rate is like pretty high, but if what you're concerned about is like, hey, I want to make sure that someone is going to catch my typos again.
Like another blog post I wrote a long time ago, and at this time, you know, this was whatever twenty eighteen or something, so we weren't even talking about AI and LMS, but I think it still kind of holds up is I wrote about like I called it like robot pedantry human empathy basically, And what I compared in that post was like, on the one side, like people are like ruber Cup, you can set to be like hyper anal right and like really really pedantic and people
could actually be fairly tolerant of that. I actually quite like that when it's dial up to eleven like that. But if you, as a human give the same code review feedback as a ruber cup up to eleven.
All your coworkers will hate you.
Yeah, often, even if you have agreed on these coding guidelines as a group or whatever. There's something about like that level of pedantry, about like if someone typo something ten times going through and every single time being like typo typo, typo, typo typo, even if you use the gat up suggestion, so it's one click for them to fix it. Like, people don't like that. They really hate it when humans do that to them. But that's the expectation that robots will do that. So that's one thing
I found is like useful on that side. But then again, like I said in that post, so part of why I wrote the post of the time is like there'd be more and more moved like ultimate shown and stuff like that, which I thought was really healthy and like CEI, but you were starting to see people being like, oh, the first time someone makes a poll request on my repo, we should congratulate that person, So let's write a bot
to congratulate them. And I remember talking to a bunch of people and they were saying like, yeah, it just it feels completely meaningless when a bot says well done, good job, you are rockstar. Now it's like, you know, it's like I'm in some empty room by myself, and you know, over the Tanoi came a robotic voice saying you are great.
You know.
It's like whereas if a human says to you, hey, right, well done.
Like I'm Pumpedy or here, like, that actually has an impact.
So that's and I think this is the same thing with with kind of code of View and Copilot and these tools and whatever. Now it's just like, you know, like Copilot can give you a review where it points out your typo is more effectively than a human can, but Copilot can't say, wow, that was really cool, Like do you solve this in half the lines of code?
I thought it's possible, Like this is a really elegant solution. Great job, right like.
And that's again much as like the stuff about humans and jobs and whatever, right like, most of us are probably not going to be okay with spending forty hours a week exclusively communicating to an LM, Like we want to deal with humans who say nice things that they actually mean that are not in the prompt right like, and that does have more of an impact and that's I feel the same way with like code review, where it's like these are complementary tools, and the human code
review and the code of view are sort of doing different things, but I'm glad that they're both there, and I wouldn't use one to entirely replace the oiler.
So I guess the other question that I was asking is what AI tools are you using these days?
Yeah, So for me, I'm mainly using like cursor as my kind of in editor like code completion thing, and like their agent modes kind of sporadically by again, I use it kind of in the in editor fashion. I still use chat GPT mainly for stuff where I'm just like asking it things where I'm going to probably write the code myself or with a bit of health, but
like I basically use that insteady Google. And then the thing that has been interesting to me recently is so I started everyone was being like all my kind of AI forward friends were like, oh, you need to use cloud code, cloud code, so sign up play on cloud code.
I was like, Okay, this is quite good. I can see the appeal.
But I think just because I'm an open source maintainer, like there's this GitHub agent pr thing where you can Now, if you have Copilot for your organization or whatever, I'm not quite sure how the pricing and the enabling works or whatever, but it works on Humbrew essentially.
So what you can do is.
You can just assign an issue to Copilot and then it will just open a pr that's like, okay, I've tried to solve this issue for you, right, And this is good that we're having this conversation today because it's fairly timely because in the last week Humbrew had I think eight open bugs on the main kind of package manager repo that I review everything on. I was like, I'm just going to sign all of them to Copilot
and see what happens. Right, And it's similar to the thing you described earlier right where it was like in most in a couple of cases it was like literally spot on first time.
In most of the cases it required me to do the last.
Like ten percent of the code right, and then in a couple of cases it was like twenty five percent of the way. They are pretty broken. I had to have quite a bit back and forth. I ended up
kind of rewriting half of myself. But even then it sort of solved the empty page problem for me, And I think it's just something about me is like an open source maintainer that it feels good and nice to just be like assign issue PR, review PR, check out PR, to finish it off, march PR, and like that's the flow instead of like this thing that lives in my terminal that I need to check and whatever.
Yeah, I like, I like you you brought up the empty page situation that that's a really good way of putting right, because I'll sit there and Okay, how do I need to put this? Okay, and then I kind of have an idea of how I wanted to go, and so I start kind of fiddle in with it, right, And instead I can just I can prompt the AI this is what I'm building. And sometimes I'll ask, you know, how should I start, And sometimes I'll just tell it to go for it.
Yeah, I'm sure.
And I found this as well, like sometimes when it's even when it's completely wrong.
Yeah, you probably heard.
That, like a comber who said this ages ago that like the quickest way to get a stack overflow answer is to answer your questions with the wrong answer.
Yeah, and then everyone will jump in and be like, no, that questions wrong. Let me tell you how it actually is.
Sometimes I feel like the same way with the LM stuff, where I'm like, yeah, sometimes it goes off and it doesn't completely fucking terrible.
And I'm like, no, that's not how you do it. You obviously do it like this, and I'm like, oh, yeah, I figured out how to do it.
Well.
What's funny is that there were there were a couple of things that I was working on with the because I'm using Curser and agent mode. The main reason is is because my employer provides us with credits on co Pilot YEP on vs Code, which is what I'd kind of gotten used to, but I don't want to use works co Pilot credits on my personal stuff, and so I use Cursor for my personal stuff and Copilot for their stuff because I'm using the same gethub account for both.
And so anyway, there have been a couple of times where I've pulled it to do something and it sits there and it flails right, It's like, yeah, I'm going to do this. Oh wait, I think I have a better approach, So I'm going to delete everything I just did and do it this way, and they'll do like two or three things and yeah, I'll finally just step in and say I've been watching you and actually I just want you to do it this way, and it'll
just turn around that. Of course, it tells me I'm smart for saying that, right, And again it's like you're a machine, you know, but do it my way. And yeah, and so just because it gets it wrong doesn't mean that it can't get it right if you give it just a little more a direction.
And to just speculate widely from a minute, I also have hypolthesis that maybe the reason why junior hiring could be done is the people who were previously responsible from entering those juniors are now essentially mentoring their lms because like again that flow you described earlier about like with rails and oh they thought I was using device and
I wasn't like that. Again, ten years ago, you could have described some new talented junior person that you hired, right and oh wow, they saved me so much time and I had to do the last a little bit to help them over the line and whatever. I think the flow and also like the stuff you like and the stuff that's really frustrating and exhausting about it is
kind of the same. And I personally couldn't imagine a day where I spend half my days supervising agentic AI workflows and then the other half doing the same thing with like junior folks who are struggling in the same way, or the worst of both worlds, which we're seeing in open source now, which is someone who is junior who is trying to use an AI agent to create a
pull request. And obviously you can't really prove this, but like I had a PR today where which round a review they were responding, and then they would paste something into an issue comment with like the slash and characters in there rather than you lines, which makes it look like it was automated, And then I would ask.
I'd be like, give a bunch of comments.
But then one of the comments would be like, hey, like, you've added two extra options to the CLI.
Which one of those are you using? Do you need both this functionality or just the functionality for one?
Because if we just say the functionality, if you only you need for one, and they would just completely ignore these questions and just turn it into more code. And I had that AI feel that I'm sure you're familiar with Charles of just like more code every time.
Every time.
The solution is we're just going to add more code, right, And it got to the point where I was like, I'm just speaking to someone's cloud code through If I wanted that, I would be using cloud code.
Myself, so I couldn't prove it.
But I just closed the PR because I was like, sorry, feels like I'm speaking to an AI, not human. And I thought to myself, I'll probably just assign this issue to compile later and see how it does, and it's probably going to be easier than what we're doing.
Oh gotcha.
All right, Well, I've got to start wrapping up, so let's go ahead and do some picks and then we'll call it good. Before we do that, if people want to connect with you, if they have questions about Homebrew, or it sounds like you will help people out for hire or at least you used to, so if there's a place for people to hire you.
I'd love to have that too.
But yeah, how do people connect with you on any of those levels?
Yeah?
Sure, The best place for me is my website at Mike mccaid dot com.
If you go there, that's called links to all my social media.
It's got all my email, it's got talks or art schools and all the type of stuff anything you might want to know about me.
That's basically the best kickoff point.
They're awesome, all right, Well let's go ahead and do some pics. I will get us started. Boy, it's been a while since I've done this. I'm trying to think of what games I've been playing lately. Here's one that I'll do. So, I don't know if you do board games much, but yeah, I do a little, not huge amounts.
Have you ever played.
Again, like a couple of times. I've never been a DM or.
Okay, So there's a game out there called Betrayal at House on the Hill, and I think that there's a book or a movie or something that related to it.
Anyway.
Essentially, you take your Scooby Dooe gang into a haunted house and you go explore the house until the how haunt starts and then you yeah, one of you becomes the trader and so then it's the Trader against the explorers until one of you wins, right, and so it gives you you know, and there are two books. There's the Trader's home, and there's the Explorer's Manual, and so the Explorer's Manual explains to them how they win, and the Trader's tom explains to the trader how they win.
And the reason there are two books is because there's some things that the trader has to know that the explorers don't need to know, or it will let help them win if they knew. Anyway, so it does that. Well, there's a version of this called Betrayal of Balder's Gate.
Balder's Gate is there's a video game, yeah, Balder's Gate, but Balder's Gate is a D and D location, and so if you ever look at anything that's Balder's Gate, you'll notice it's Wizards of the Coast, which is the company that does D and D and so anyway, so Betrayal at Balder's Gate is Betrayal at House on the Hill with the D and D elements from Balder's Gate.
And so instead of exploring rooms, you're exploring areas. And you have the city like the streets, you have indoor areas, and then you've got the catacombs underneath the city, and so you can kind of explore or whatever you want and there's some differences, but yeah, the rest of the elements are the same. And so if you're kind of like that, it doesn't have like strong story elements. It really is just a you know, an explore and then
you know, fight off the monsters game. But it's fun and yeah, I played it with my guys group a couple of weeks ago. Board game geek waits it at. I have six so you know, your casual gamers. It's mildly complicated, but not so complicated that, you know, folks that just like you know, a casual board game among friends, wouldn't just pick it up nice. So I'm going to pick that up. I'm going to pick that it came out in twenty seventeen. I don't know if it's still
in print. That's the only caveat I have on that. And then on the other picks, yeah, I've really gotten into using the agent mode on Cursor, and so I'm going to pick that as well. Incidentally, I was just kind of goofing around and I thought, Okay, well, how much work would it be to get it to essentially vibe code React native app, a podcast subscription app.
And I have to say that it did pretty good.
It doesn't have all the features I want in it yet, but it's good enough to where I'm starting to think about whether or not I actually want to release the sucker onto the app stores. And so you know, and I'm not a React Native developer by any means though, again, that's another technology I want to pick up because we use it at work. So anyway, so I'm gonna I'm gonna pick that as well. And then within React Native, I'm using Expo.
Yeah. Pretty cool. But yeah, Mike, what picks do you have?
Yeah, so I guess my game related pick would probably be avowed. So that was recommended to be by don't know he's been on this pod before, but certainly legend of the Ruby community justin Searles. Oh yeah, sort of
like you know, it's made by Obsidian. It's like a kind of Bethesda esque like story driven RPG and it's just, I don't know, like if you liked all those old school rpugs like Oblivion and Skyrim and whatever, it's got that vibe, but like lots of nice like quality of life things like, so if a character ever uses a sort of bit of jargon, you can just press a button and then a glossary pops up that sort of defines a specific bit of jargon they used, and I'm like, yeah,
I want this in every RPG now, And like, you know, if you're a made you have a wand that casts stuff and it doesn't require man and you know, like lots of just like little things that have annoyed me in other games. So yeah, I'm enjoying just exploring that. I imagine it's one of those games I' probably gone hundred percent just because like the world is interesting enough.
Yeah, what's it called again.
It's called Avowed avowe D. And then my, I guess if you're not gamer like TV wise, we've been watching Tokyo Vice, which is pretty interesting about this guy who's a journalist and kind of lots of stuff with like organized crime in Japan. That's kind of what network it's on or whatever. But that's been good, so only two seasons of that. We're about halfway through the second season. Enjoying that a lot.
And then I guess on the computer land.
I guess, yeah, I mentioned it already, but I would probably say the copilot agent mode where you can assign it from assign it an issue and it will then create a pr there's a bunch of rough edges there, but there's something about the workflow that feels pretty different to like running agents locally, and has a different trust model in a good way in that like you can let it just run arbitrary commands and it's running in some random dog continuing and get ups infratructure that you
don't care about compared to your local machine.
But yeah, but for if you're someone who lives in prs all of the time.
Then it might be worth seeing if that's an agent flow that works for you more than like some term or lap or some window in your right idea or whatever.
Cool. Well, thanks for coming. This was fun.
Yeah, thanks for having me always your fun line.
Yeah, I'm gonna go ahead and wrap us up until next time, folks max out