Building a Developer Tools is a rare thing where you are the same person as your target audience.
The problems that they have or the problems that you have
and bringing people together to discuss this and potentially be able to fix it together
is powerful in a way that most startups can't go to their customer and say,
hey, let's make this better together.
Hello, welcome to the DevTools FM podcast.
This is a podcast about Developer Tools and the people who make them.
I'm Andrew and this is my co-host Justin.
Hey everyone.
Today we've got Brendan and Matt joining us from FIG.
FIG is a pretty magical autocomplete experience for the terminal.
Brendan and Matt, would you like to tell our listeners a little about yourself and how FIG came to be?
All right, so a little bit of background on us.
Brendan and I met our freshman year of college
and we've just been hacking on-site project ever since.
Like when we were in school, we built an events app together.
Like the classic startup that everyone in college tries to put down.
That was an early learning experience.
We built a bunch of other stuff along the way.
And so when we were thinking about what we wanted to do after college,
we loved working in tech.
We knew we liked building things together and so we're like, hey, let's try to start a startup.
And so we were lucky that we got into YC through this kind of unusual early decision program.
So we applied in October, knew we were, the October of our senior year,
knew we were going to get into YC,
but then we had this six month period where we had the investment,
but we were still in school and like the YC program hadn't started yet.
And so that was when we started like really drilling down and trying to figure out what we wanted to work on.
And so we'd applied with one idea, we'd pivoted before our interview.
So we were kind of in this spiral where we're just going through a ton of things,
building lots of stuff and just seeing what stuck.
And in the process of doing that, we honed in on this pain point for ourselves.
We're like, okay, every time we're building something new,
we're spinning up a postgres database, we're deploying something on Heroku.
There's all of this stuff we do in the command line that is essential to get a project off the ground,
but is surprisingly hard, especially if you aren't doing it all the time.
And so that was kind of the core idea behind FIG early on.
It's like, how can we take this sort of intimidating environment
and make it really easy for anyone to get set up quickly and use like a power user?
Yeah, I think just adding onto that a little bit.
One thing that said, so we got into YC in October 2019,
but we started YC in June 2020.
Obviously, we didn't know the pandemic was going to happen,
but we had this unbelievable six months where we're working on ideas.
We had every aspect of YC, except the sort of boot camp.
So we had the money, we had the partner access, we had the community.
And so what like our problem was in the early stages, we had ideas.
We weren't physically solving problems.
And in building the ideas, we found that, oh my God, the terminals, actually a big problem.
Not just for us, we're talking to our friends and they would say, oh yeah, like,
why the hell this tool was built in the 70s?
Why the hell is it exactly the same?
And I have to use it at work and we're not getting trained on it at school.
And that's really the genesis of the idea.
Happy to talk more about what happened during YC and how we got to autocomplete
because that's another few months of, I wouldn't say pivoting,
but we identified the space that we're excited about.
But I think just because you identified the space
doesn't mean you have found the exact thing that you want to work on.
But where did that start?
We've ended up at autocomplete
and from what I've gathered through looking at your Discord
and that future plans to come and there's like this fig core that powers it all.
But like, where did it start?
The idea originally was tutorials in the terminal.
The problem we had was we were trying to set up a Postgres server locally.
We were trying to fork a production database
and we're going through the exact same medium article every couple of months
as we pivoted ideas.
And sometimes like, you would follow the same steps and things wouldn't work.
And so the original idea was can we sort of overlay these tutorials in the terminal?
Literally the idea of context switching.
I'm going to my browser, I'm copying code, I'm putting it in the terminal.
I'm running it, it's not working.
I go back to my browser.
Like can we just solve that problem?
And then the way Matt actually built it was maybe it was so much harder
than it should have been, but he sort of built this API
which allowed you to build any UI in the terminal.
And what the API would do is it's just a web view,
but we could dock this web view to the terminal window.
We could also read and write to the local shells.
We could do the file system operations, that sort of stuff.
And then finally we could paste code into the terminal.
So we started off with tutorials, but then we realized that
oh, there are so many other problems that people have that we could solve.
And so we started just during YC, especially building apps, essentially.
We see this evolving to a visual app or extension ecosystem for the terminal.
And the way we started was building this API,
which enabled us to even build these apps.
Yeah, it's pretty fascinating.
When I first got started with FIG,
I still had the run book like ask sidebar thing.

And I was like, how does this work?
Matt, do you want to talk a little bit?
I know you're doing a lot with the accessibility API,
but I'm curious, how did you get to come to that conclusion?
Yeah, I have an iOS background from when I was younger.
I would just throw together some various little side projects there.
So I knew the Apple ecosystem,
but what was really fun about going from iOS to Mac is how much more open stuff is.
Like on the iPhone, things are like really siloed.
If you don't have access to something through an Apple approved API, you can't do it.
Whereas on the Mac, if you're outside of the sandbox,
if you're not distributing on the App Store,
like you really have access to the computer
and that lets you do super cool stuff.
In this really early stage,
when we were just trying to add tutorials to the terminal,
I was like, how can we do this without needing to build the terminal
from scratch? That's not the core problem we're trying to solve.
So if we wanted to integrate with existing terminals,
we had to do some kind of hacky stuff.
And this is where I came across the accessibility API.
And that's really powered a lot of the integrations.
But what's interesting is the terminal environment
is actually pretty open and extensible.
So in order to create the seamless experience that we think we've done,
you actually have to integrate it a bunch of different levels.
You're building integrations at the shell level,
you're building integrations at the terminal level,
you're building integrations at the operating system level.
And so the accessibility API, along with a couple of other things,
is the integration with Mac OS.
But we've also had to go in and build a custom VS Code extension
and write a bunch of weird, like ZShell line editing widgets
to get the information that we want.
And then the Mac app takes all of these inputs
and synthesizes it so that the web view has this kind of clean API
for dealing with all of these terminal events.
Yeah, that's awesome.
I imagine that that is an incredibly hard thing to do,
generally because of like first just digging down into the accessibility API.
We were talking about this previously, but it's like,
okay, you have to know where the cursor is in the terminal.
And that takes some very particular tunneling.
But beyond that, it's like stitching all of these sources of disparate information.
That seems like a hard problem.
We've both taken a really incremental approach to this.
We started off just being like, okay,
we are going to make this for ITERM and maybe it's not going to work anywhere else.
And then once we had it working, like some really, really prototype in ITERM,
we're like, okay, well, just by tweaking this a little bit,
we can also support the native terminal app.
And then it was that iterative approach that slowly we expanded
from just supporting one terminal to also VS Code and Hyper.
And we have some plans for Alacrity and Kitty coming up.
Once you find the core architecture, it's just figuring out like the new little hack
that gets us on the next platform.
To really emphasize how this works, it is exactly as you said, Justin,
you are using ITERM.
We don't own ITERM and there is a cursor in ITERM
and we need to dock the FIG app next to that cursor.
So all the layers we have to go through at the operating system level,
like what window is currently open on the screen.
And then you go down to the terminal level, what tab is open,
how big is the width of the menu bar at the very top.
Are you in a specific pane?
Are you using something like T-Mux or even the panes in ITERM?
Or if you're in VS Code, is the terminal even the active sort of little module
at the bottom of the screen right now?
And then you have to go to the shell level.
Like, okay, what shell are you using?
Bash is very different to Zshell is very different to Fish.
And then finally, there's the CLI integration.
So if I type CD, how do we know you've typed CD?
How do we get that text out?
And what if I type in CD, semicolon, git space?
Like, how do we know that git is the thing we should be completing on, not CD?
Yeah, it's just been like integration after integration after integration
from the OS all the way down to every single CLI, so there is.
That sounds like a nightmare to test.
It is.
We started figuring out some more scalable ways
because for a while it's like we just had a suite of tests to do for version releases.
And we have a hack together Apple script
that actually will mock keyboard events into like various different terminals.
And so we just take screenshots and make sure that stuff is semi working.
But yeah, there's a ways to go in terms of making it more robust.
That's awesome.
One of the things when I had first heard about that,
and then when y'all launched on Hacker News recently,
we saw a lot of feedback about it is just,
developers are a very particular group of people.
And there are certain things that they just get really, just really paranoid about.
And privacy and security often are something that like,
they're very paranoid about.
So I feel like I did a pretty good job like responding to a lot of the concerns raised in Hacker News.
But when someone asks you, it's like, hey, well, how do you think about privacy
and how do you think about security giving that being that you're building a tool
that has access to someone's shell, which has the permissions that they have?
Like, how do you approach that?
I'll condense down the big criticisms from the Hacker News post.
Hacker News is obviously its own hive mind.
There are a lot of vocal people and then there are a lot of lurkers.
So we take everything with a grand assault.
But yeah, the key criticisms, which I think and Matt thinks as well,
are totally fair.
People are saying, why the hell do you have a login for this?
Like, why should I even put my email in?
You're literally doing auto-complete for the terminal.
Totally makes sense.
Second thing was, why do you have any telemetry whatsoever?
Like, why is this not opt in?
Why is it opt out?
Also, like, has been discussed about so many things.
It's been a problem forever.
Like, totally agree with that.
And then the final thing was, like, what is your business model here?
Like, you're literally doing auto-complete for the terminal.
If you're not charging me for it and you said you will never ever charge me for it,
you're either selling my data or you've lied and you are going to charge me for it.
So, like, all three of those criticisms, totally valid, totally fair.
And I, like, to address each of them.
The first thing is, yes, why the hell do we have login for auto-complete?
Even taking a step back.
We maybe did a bad job of pitching exactly what figures.
Like I said earlier, we want to evolve it into this ecosystem of visual apps and extensions
and shortcuts that hook into the terminal.
Auto-complete is just the first app there.
It's macOS only.
We want to go into all of the operating systems.
We want to work with all the terminals.
Maybe we'll build our own terminal.
We have so many other apps planned.
What we found during YC is we were trying to work on way too much.
So, we just decided it was really hard at the time.
Let's just put aside everything.
Let's put aside the API.
Let's put aside all of the other apps.
Let's just focus on auto-complete and let's do the best possible job we can do at auto-complete.
And so when Hacker News looks at it and they're like,
I already have auto-complete with ZShell or Git.
How is this different?
How are you going to make money out of this?
Yeah, totally valid.
Yes, we are not going to charge individuals for auto-complete.
Maybe we'll have some team functionality on top of that.
But what we're really excited about in Business Model is all of the other team collaboration apps that we can actually build here.
So, that's the longer term business model.
And we definitely did a bad job of conveying that in the post.
The second thing is why do we have a login?
And in early, early days of FIG, we had zero telemetry.
We had zero login.
We had absolutely nothing.
And we would give it out to 100 people and we would get zero feedback.
We don't even know that they downloaded.
We totally understand the terminal as a sense of environment.
That is an absolute given.
Do we want to see your AWS secret keys?
Absolument not.
No, we know that sense.
We know that there is so much secret stuff going on there.
And also, do we even need to know what commands you're using?
It's probably CD.
It's probably Git.
It's probably LS.
There is a list of 10 that everyone uses.
None of that matters to us.
What we want to know is, really, the reason why we ask for the email is not to tie everything you were doing in the terminal.
If you download FIG, you'll get emails from me.
You'll get an email, like, 2 seconds after downloading it, 2 hours after downloading it, 3 days, 2 weeks, like another 4 weeks.
And it's just for feedback.
It is us saying, hey, you've just downloaded FIG, like, it is super sharp.
I'm saying, this is an automated email.
Tell us what you think.
What is your feedback?
What works?
What do you love?
What do you hate?
What doesn't work?
If you want to install it, give us some more information.
That is it.
And so many developers don't mind about this email.
They don't mind about these emails because this tool is adding so much value to it.
And we know that a lot of developers do mind about that.
And so the calculus we've made is if we want to build, like, the best possible sort of ecosystem for the terminal here, we just need to have people giving us feedback.
And we found that having the email there is totally going to, not a noise, probably the wrong word, but there are going to be people who just won't use FIG because of it.
We totally understand why.
And so our thesis is there are tons of other people who don't care at all about the email, who want this tool because it adds so much value to them.
They're going to give us the feedback.
So we're going to use that feedback to make it better and better and better.
So when we do give it out to thousands more people, suddenly we don't get any more feedback anymore.
We hit the end goal we want to hit.
And then we can just get rid of the email and then we've opened it up to everyone else.
So we see it as this iterative cycle and we totally understand privacy concerns.
We totally understand telemetry concerns.
And our thing is the best we can possibly do here is be super upfront and say, here is exactly what we're doing with your data.
Here is exactly what we're doing with the email.
We know that telemetry and privacy in the terminal is a sensitive environment.
We want to try and avoid any of this at all costs, but we are upfront about what we're doing.
And in the future, we're doing this so we can build the best possible product.
And in the future, we're probably going to get rid of 90%, if not all of it.
And hey, if you want to opt out entirely, you also can do that up to downloading.
One thing that I've noticed about FIG is you guys have really started to bet on the community.
You have a very active Discord.
And I assume your strategy going forward is you don't want to write a autocomplete spec for every CLI tool in the world.
So what is your guys' approach to open source and community?
Yeah, so I think in general, any good developer tool should have a community behind it.
Building a developer tool is a rare thing where you are the same person as your target audience.
The problems that they have or the problems that you have and bringing people together to discuss this
and potentially be able to fix it together is powerful in a way that most startups can't go to their customer
and say, hey, let's make this better together.
And so yeah, to the point you were saying about CLI tools, the terminal kind of ecosystem is enormous.
There are so many different tools, there are so many different workflows,
and it would just be a point of hubris for Brendan and I to say, we know exactly how everything should work.
And so what we've decided is let's make FIG as extensible as possible
so that it can cater to all of these different use cases so that people can customize it for themselves
and for their teams and for the tools that they use every day.
So when it comes to open source, I think the main thing that we have been focusing on now
is just building out our selection of autocomplete for every CLI tool that's out there.
So the first couple of ones, Brendan and I were writing, and these were the tools we used.
We did a pretty good GetSpec, though there's always room to improve.
We did CD, we did LS, we did a lot of kind of the Unixi ones.
But again, I'm a MacOS, IOS person, but my background is there.
I don't know PHP, I don't know like Laravel, Artisan.
And so this has been the coolest part to see the community coming together
to really contribute super high quality completion specs for these tools
that like I don't know the workflows, so I wouldn't have been able to do myself.
And I think that's the advantage of open source, is you can get people to contribute stuff
that is better than you ever could.
I think there's a really strong sense of shared ownership
when you have the ability to contribute to an ecosystem or contribute to a tool directly.
This is something that I've always been fascinated with.
When I was younger, I liked to play games a lot,
but the games that I was drawn to were the games that I could write minds.
It's like I want to modify this, but not only do I want to change it,
I want to see what other people do with this space.
Like today, one of the apps that I use the most is Obsidian,
and most of my time is spent using plugins for Obsidian
and building my own and watching other things people built.
And so I think this opening something up to extensibility,
especially in the terminal, which is a workspace
that a lot of people spend a lot of time in, it's a smart move.
One other point around community in general,
the terminal has traditionally been pretty isolated.
Like you do it on your local machine,
maybe you can look over somebody's shoulder to see their workflow.
But most of the time, you just stumble across these little hacks.
Like I can search my history directly from the command line by pressing control R.
It took me a long time to figure that out
because there's not some little tool tip that pops up when I'm typing out history.
You just have to come across that.
And so it's a weird thing where the way people learn about the terminal
is entirely through the community, but there is no place for this community to come together.
I guess like Stack Overflow would be the closest.
That's been really exciting to just learn from other people,
how they use the terminal, how they extend it, how they customize it.
I learned new stuff every day.
I learned new CLI tools, I knew learn new commands, I learned new hotkeys.
Even if you're not as excited about Fig Autocomplete,
you should still join the community
because people have all of these crazy tips
about how to supercharge your terminal experience.
Yeah, early in my career, the terminal was definitely a point of contention for me.
It was like, literally one time, I accidentally deleted a project for school
two hours before it was due.
I RMRF'd in the wrong place.
And the terminal itself is just such a clunky UI for beginners.
And I like that Fig is lowering the barrier to entry
to being proficient on the terminal.
Because really, like most of those power users probably don't need to use Fig,
but power users aren't the majority of people.
One thing that is so interesting with Fig is the terminal
or the shell is just this black box.
It's not even a blinking cursor.
It's like a square cursor.
And you type something and you have no idea what's going to happen
when you hit enter.
You are just, like every character increases the permutations of what could happen.
So you really have no idea.
With Fig, it gives you the confidence to actually hit enter.
We try to give you the whole world of what can come next
in order to complete it at least.
It's like, all right, there are 50 different things
I could possibly type next.
Which one I type it.
And if Fig isn't showing suggestions,
okay, you immediately go something is wrong,
something's wrong.
But when Fig's there, we really try and have a very, very high accuracy grade.
So if we don't have proper support for a CLI tool,
I would rather not have it there.
Because when people see Fig, I really want them to trust it.
And it to be like, all right, when I hit enter, this is just right.
I think that confidence makes it so much easier to get started in the terminal.
But even for the more productive engineers,
the really hardcore people who use the terminal all the time,
it can also just increase your typing speed.
You can have aliases to do things,
but you're typing out some long file or folder part.
I don't want to type the random things with all the underscores.
I go to hit enter and it's done.
We do try and make it so it goes all the way from beginners.
I've never used the terminal up to like hardcore proficient terminal users
who want to learn more about specific CLI tools
or literally just want to type faster.
Yeah.
And we really do have people across the spectrum.
This is not a tool just for beginners.
I think one of the interesting things about being a programmer
is that you are always a beginner somewhere.
So maybe we probably know how do you CD and LS
and some of these more standard Unix commands.
But when I am spinning up some Kubernetes cluster,
that is new to me.
And it is really, really helpful to have the suggestions
like around pods and namespaces
and just get the standard workflow first
so that I'm not constantly bouncing back and forth
between man pages and the browser
to find help text and stuff like that.
Yeah, it's almost like a similar argument for TypeScript.
Like it does help your younger developers.
There's documentation at your fingertips,
but it helps you be more confident along the way.

This was actually in a different hacker news post.
Somebody made the comparison between FIG and TypeScript.
And I think it's actually, I hadn't thought about it that way before,
but what a completion spec does
and a completion spec for those who don't know
is the format we use to define autocomplete.
Basically, it is adding a type definition to a CLI tool.
You are defining the structure, you are defining the arguments,
you are defining the commands,
and that's what enables us to figure out what you've typed
and provide the accurate suggestion.
So in a lot of ways, it's very similar.
Like we are giving you the confidence,
we are providing the suggestions,
and yeah, it's like the similar transition
between going from JavaScript to TypeScript,
going from the command line without FIG
to the command line with FIG.
There's this project called Shell Explainer.
Have you ever seen this?
It's kind of what I think of it.
It's like you almost have Shell Explainer
explaining things to you as you're typing,
but just through the autocomplete spec.
So yes, it's good stuff.
Yeah, it's a project that everyone should check out.
It's super cool.
I've built a bunch of CLIs
and validating user input is always a hard problem.
Like for Auto and Open Source Library,
I maintain, I use IoTS,
which is super complicated,
and I had to write my own adapter to extract errors out of it.
Do you guys have plans to like make an Open Source package
that helps you just use your autocomplete spec
to create a CLI,
or at least a validation function for a CLI?
I'll chime in here.
One of another cool CLI tool that I stumbled across
was DocOps,
which basically takes the synopsis of a command line tool
and uses that to generate the parser.
And so, yeah, like the short answer is yes.
We are super interested in making it really easy
to one generate a completion spec for a CLI tool,
but also integrate at the CLI level
when you're doing all of this stuff.
Because right now, we're coming in on top
and providing and building a completion spec
to mirror the CLI tool.
But the more these things are the same
and use the same source of truth,
the more accurate they'll be
and like the more powerful things we can do with them.
Like enabling developers not to need to do the validation
because that happens at a different level.
Yeah, it would be really cool to have flags
that are dependent on each other
because that's something you have a lot
where you have to have one flag and then another flag.
But if you have this type definition going,
you can validate that and not even run a command
if it doesn't meet that.
That's definitely one thing we're excited about.
The completion spec is mapping to existing CLI tools,
but why can a completion spec not be its own CLI tool?
And you can even take that further.
You have to write a script in bash.
Why can you not write some Python script
and have that script executed
and then node in a different section of the CLI tool
bash in a different section?
Whatever language best fits the goal you are trying to achieve,
just use that as opposed to using clap
and then you have to write the entire CLI Rust
or click and it's in Python or OCliff
and it's all in JavaScript.
Yeah, like we're actually in early stages of FIG
when we had the sidebar and we had everything.
We also had a drag and drop CLI builder.
You have a sub command, you can just keep nesting them
and then you can choose all the options you want.
You can add the descriptions and then you can choose
what script you want to execute.
Obviously, we've put it to the side,
but all of this stuff is exactly what we want to get back to
and we think FIG is just such an easy interface to build this.
So one thing we've been dancing around here
and I want to spend some time talking about it
because I think it's really fun to think about.
So the things that you're having to do with FIG right now,
it's like digging to the accessibility API,
find out where things are, like show this autocomplete.
We're doing these things because the terminal
really hasn't changed very much.
And there are new implementations of the terminal.
So I could see, you could take Hyper, for example,
which is an electron app,
and you could ostensibly probably build an autocomplete module
that works inside of Hyper, just because it's HTML.
But in the future, to get really, really rich,
really, really interesting interactions,
it almost seems like you're going to have to think
about, okay, if we were to build our own terminal,
what sorts of things would that need?
And I'm curious, I know you're not thinking about this right now,
but let's thank Pi in the sky.
What does that future look like?
I think sequencing is really, really important
and this is a lesson that we learned through YC.
We came in with this really grand vision of building an app store
and then we realized that the sequencing was really important.
So rather than trying to start off
and build a full featured app store
where we had all these APIs and all this documentation
and a distribution model,
it's like, that isn't the right place to start
because you don't have users, you don't have developers,
you don't have the kind of necessary things to get started.
And so that was why we decided to hone in
really deeply and narrowly on autocomplete
because it was like a small thing we could do
just as the two of us with a couple of other people
and prove out this API
and kind of take that to the next step.
Okay, but that said, we are very excited about the potential
of what a new terminal emulator could look like
et que ce que l'on peut faire,
c'est qu'on peut avoir un model qui ne s'occupe pas de la tête
et un projet qui est vraiment cool,
c'est le term kit qui a été fait,
je ne sais pas,
il y a un an,
qui a été pensé sur ce que ça pourrait devenir
si on avait l'output visual
et le commandement de la réponse
plutôt que seulement en utilisant le texte,
il y avait peut-être les affords pour les interactions riches
directement dans le terminal.
Et donc je pense que
il y a beaucoup de valeur
pour que les choses soient compatibles
et je ne pense pas que si vous avez jamais construit un terminal,
vous devez en faire sure que les mêmes uniques
sont en place, les mêmes workflows sont là,
mais je pense que le pouvoir,
le pouvoir d'avoir un set de feature
sur le top de ça est super cool.
Je peux totalement imaginer que le type de figures
que les gens sont construits
comme des barres de l'extension,
ça pourrait être intégré au terminal
ou si vous avez fait un commandement
et l'output fait plus de sens
comme une forme ou un texte
plutôt que juste comme un texte
rendu en utilisant les specs VT100,
je pense que tout ça est sur le table
et c'est le genre d'interessant
pour penser en construisant nos APIs.
Ce que la API est maintenant
est actuellement utilisé par notre accessibility
et notre macOS app,
mais à un moment, ça peut juste être nativement intégré.
Et donc c'est un challenge intéressant
de savoir ce que nous pouvons supporter maintenant
pour que quand nous pensons en faisant ça plus sérieusement,
nous pouvons faire surement que
quelles des apps existent maintenant
puissons faire le transition
à un terminal native.
Un truc que je pense un peu,
c'est que c'est bizarre comment le terminal
se ressent si vous jouez en un repos
et que vous pouvez vraiment vite
avoir des réponses et essayer de les tester.
Vous pouvez le faire en terminal,
ça ne se ressent pas le même.
Je me sens comme une opportunité
pour que ça se brise un peu.
Le plus cool de la termine est que vous êtes
super proche de la machine
et ça vous fait bouger très vite.
Et donc je pense que tout ce que nous
finalisez en ce sens,
je ne pense pas qu'on va avoir
une expérience de cette manière.
C'est un très cool part
de la utilisation de la shell.
Dis-nous un peu
ce qu'il y a à la prochaine.
Vous êtes en train de travailler
au complet et vous êtes très fous
de prendre des études d'intérêt.
Qu'est-ce que votre prochaine étudiant?
Qu'est-ce que votre prochaine étudiant?
Comme vous l'avez dit,
en plus de la C,
nous avons essayé de faire tout.
Ça ne marche pas,
on va faire un truc.
On pense qu'il y a un peu plus de temps
pour faire le complet.
Mais on veut avoir le machine.
On veut avoir le machine en allant.
Quand les specs sont contribués,
ils sont réchauffés,
on fixe les bugs qu'on doit fixer.
Le standard pour faire le complet,
cata à tout le CLA,
on va avoir 100%
mais on veut aller de 95%
à 99% à 99,5%.
Je ne pense pas que ça va prendre trop longtemps.
Mais sur le côté,
la prochaine chose que vous voulez faire
c'est d'ouvrir les APIs.
L'extensibilité de ces études
fait que c'est trop mignon pour les développeurs.
C'est vraiment
le seul moyen
d'en commencer cet écosystème.
Pour ouvrir les APIs,
pour que l'on fasse des apps,
c'est un peu standard.
On doit faire sure que ce soit pas changé.
Le plus dur serait de
rééter le core de l'API
et de chaque semaine.
On ne pense pas que ça va prendre trop longtemps.
On a construit l'API
avant, on a même l'a élevé
et on a délivré le plus tôt.
Il va être en train de réacte,
réacte,
réacte, et tout le monde.
Tout le monde s'est réélevé.
On peut construire le même API
sur la plateforme.
Avant, on avait
une page app store,
on a une page app store,
on a une app store app.
On peut construire le même app
et on a le standard.
Un app store peut être
un README.
On peut construire 50 apps,
mais il n'y a pas besoin.
On a le stabilité et le travail.
Nous sommes aussi en train de
faire une plateforme.
On a le temps de
faire des integrations
avec chaque plateforme.
Nous explorons les deux
en regardant ce qui est possible
et ce qui serait le meilleur.
Le dernier,
si nous construisons
l'accent d'expérience
quels sont les next apps?
Vous avez vu très très
très très en face.
On a l'air d'exprimer
et de ne pas savoir.
On a l'idée
d'une partie,
d'un processus ou d'un workflow
que vous voulez faire.
Vous devez faire
votre workflow de githé,
d'enregistrer
des services micro
pour tester un changement.
Vous avez un série de procédures
que vous devez aller par.
Les deux moyens sont solides.
C'est en un moment de notion,
peut-être en conflurent.
Vous devez en faire un code
et de lire les instructions
très très bien.
C'est de l'environnement de développement.
C'est très descriptif et si quelque chose va bien,
vous pouvez l'écrire dans le futur.
Les deux procédures sont un script bas.
Un script bas est
dans le même folder.
Il vous dit exactement ce qu'il faut faire.
Mais si quelque chose va bien,
pas beaucoup de gens peuvent le faire
et le fixer.
Et puis, comment vous commencez?
Un script bas ne vous dit pas
que vous avez des options
et des flags,
c'est juste un file.
Vous devez le faire
et vous devez le faire.
On pense que c'est un bon terrain
pour les deux procédures.
C'est vraiment descriptif,
et il ne se déploie pas
car c'est très important
pour les deux procédures.
Mais sur le flipside, c'est aussi facile
et plus facile
pour le développement de la base
ou d'autres scripts.
Et en combinant ces choses
et en imaginant ce que ça ressemble,
on est vraiment excité.
Parce que je pense que ça peut changer
pas seulement les individus,
mais aussi les individus qui font
un processus dans leur environnement
et les séparer
et les épargner.
Et en même temps,
les Github Gis
y a des millions de workflows
en ligne.
En termes de workflows, les gens
sont très déploies
pour ma Harokus.
Je dois me mettre un file
dans un S3.
De partager ces files
et les établir ensemble,
c'est vraiment cool et compétent.
Et donc, en prenant l'infrastructure
et les biais,
on va prendre du temps
et on va en parler.
Et en faisant ceci,
c'est toujours extensible.
Je peux toujours construire sur le dessus
et puis, de partager.
Je peux prendre l'adaptation
de la partie que j'ai faite.
En parlant de ça,
j'ai l'idée que c'est super cool
d'avoir des overlays en bas.
C'est un cas de use cool pour FIG.
En fait, si tu fais FIG,
un file shell,
tu peux hover ou quelque chose.
C'est cool.
Peut-être que tu peux construire la app pour nous, Andrew.
Hey,
je construis beaucoup d'abandonnements
en source open.
Je pense que c'est quelque chose que je suis vraiment excité
pour les livres de la run, en particulier.
C'était mon premier exposé pour FIG,
donc tu es toujours en pensant
sur ce que ça pourrait devenir.
Mais il y a des espaces
entre documentation et automation.
C'est comme,
d'une à l'autre, c'est un processus assez expensif.
Et quand tu penses que c'est pas...
C'est la trappe, c'est quand tu te trouves
un bascour sur un service
et tu te trouves un nouveau service pour faire ça.
Et ça va, et les gens vont
dire, ah, tu sais, ça va.
Et l'autre chose, si quelqu'un en roulant un bascour,
n'est pas en train de apprendre ce qui se passe.
C'est une bonne opportunité d'éducation.
Mais je pense que la plus grande chose,
et je ne suis pas sûr si tu penses ça,
est la plus grande raison pour que les choses
ne passent pas
quand tu es en train de faire un document.
C'est parce que ton environnement n'est pas correct.
Tu es en train de perdre un environnement,
tu es en train de perdre un command
que tu as installé.
Et si tu n'es pas dans le contexte
d'un terminal, tu ne peux pas savoir
ce que les gens ont installé.
Mais je pouvais voir un monde
où tu es en train de définir
ce document. Mais tu peux dire, hey,
ce document dépend de
avoir cet environnement variable et de
avoir cet command installé.
Et ce n'est pas quelque chose que les gens
doivent penser activement, tu peux juste checker
ça dans le background. Et si c'est
faible, tu peux le faire pour eux
ou donner des notifications, etc.
Les workflows comme ça
sont super fortes.
Et avoir une construction de terminal,
c'est super.
Je suis excité.
C'est tout ce que nous pensions
sur les tutorials,
quand FIG était juste un product pour les tutorials.
C'est super cool de te voir vous le faire
pour que ça se repasse.
C'est comme maintenant que nous commençons
à se faire un tour de la vision.
La progression naturelle est super incroyable.
On va le faire.
Andrew,
on va faire des tutorials?
On va faire des tutorials.
Mon premier tip de la semaine
est Postico. C'est un Mac app
pour regarder un client post-grace.
Un grand événement a été arrivé dans ma career professionnelle
cette semaine. Je l'ai fait pour la première fois
en code en bas.
Et avec ça, il y a des nouveaux tools.
Je ne sais pas si il y a d'autres tools
comme ça, mais je suis sûr qu'ils existent.
Mais ça a été super facile
de browse mon database.
Je me suis surprise
de la vitesse que je pouvais développer
mon processus de la fin de la fin.
Je fais un server de la run
et puis j'utilise le terminal pour ça.
Mais le terminal m'a pas été en train
de utiliser un database
comme ça très souvent.
Donc, ça a aidé beaucoup.
Un point de vue fun.
Je suis sûr que c'est super
un moyen naturel
d'avoir access au tout.
Je suis sûr que c'est un des trucs
qui me sentent très bien.
Une des appels plus rapides que nous avons
construite quand nous étions
protétenus sur la direction que FIG
ferait, était une cliente
de post-grace.
Vous pouvez visualiser les rôles
et les columns et tout dans votre database
sans déterrir le terme.
Je pense que les choses comme Post-it
vont vous montrer
comment certains interfaces sont
plus meilleures
ou peuvent être augmentées
quand ils ont un UI,
plutôt que juste.
Et Brendan built ça.
Si vous voulez en parler un peu plus.
Oui, c'était comme de copier.
Je ne sais pas si c'était post-it
mais c'était comme de ne pas savoir
le Swift UI qu'on a besoin de
mais je sais HTML et j'ai l'obligation
de faire le PSQL command
dans le terminal,
de l'outil et de l'enlever dans la table.
Ce n'est pas une grande fonctionnalité
mais je ne pouvais pas
prendre un week et faire
quelque chose de bon.
C'est cool.
Il y a un bon overlap.
En dernier épisode,
nous parlions de
Nato,
il a été en train de représenter
le programme dans différentes manières.
Il y a un programme textuel
qui est le norme.
Il y a peut-être des modèles.
Nous sommes en train de parler
par rapport à la termine.
Nous avons un traditionnel
où tout est textuel,
des columns textes et tout.
Peut-être qu'il y a un futur
où nous avons une expérience
multi-modèle de terminaire
pour faire les interactions.
C'est cool.
Sur le sujet
de terminaire et de CLIs,
j'ai rencontré un document
de la best practices de CLI.
C'est vraiment cool.
C'est un certain nombre

que vous devriez penser
quand vous étiez un tool CLI.
Il est parmi les idées
de la note.
Il y a des idées qui sont transpare
et beaucoup de ces idées sont relativement
des idées.
Les idées standardes
sont les commandes de CLI.
Mais il y a des idées
qui sont incitées.
Réussir les préférences des utilisateurs.
L'automatique est configurée.
Quand ils arrivent, ils ne doivent pas
réconfigurer ou ré-douer les mêmes idées.
Ça va être plus facile.
La idée de construire un CLI
est une bonne idée.
Il y a beaucoup de ressources
si c'est quelque chose que vous êtes intéressés.
Je voulais donner quelques tools de CLI
qui sont dans la communauté
qui sont super utiles.
Et qui s'est complètement solide
que vous avez parlé de ça en podcast.
Si vous êtes un RM-RF
ou quelque chose,
99% de temps est déçue.
Si vous ne touchez pas votre système de file
et que vous trouvez le bon stack overflow,
vous pouvez peut-être le recouper.
Mais les chances sont que c'est déçue.
Trash est un tool de CLI
où il bouge
votre file ou le folder
dans le trash,
en tant que de l'acid.
Vous pouvez aussi faire
un RM-RF
pour trash.
Si vous faites un RM-RF,
les alias vont vous changer
pour trash et ce n'est pas déçue.
Je pense que les flags vont travailler comme vous l'avez prévu.
Un petit petit tool
et vous ne pouvez pas les mettre
ou vous pouvez les mettre
si vous avez besoin.
Un petit tool qui est vraiment utile.
Comment ne pas surprise que c'est de Centrosaurus?
Le module Node Master?
C'est pas cool.
Comment est-ce que le mec
est un app-tool?
Il y a des libraries
d'open source
sur chaque plateforme.
Vous cherchez pour quelque chose
et vous parlez.
Très bien.
C'est un guide
qu'un de nos amis
a fait, Ben Fershmann,
et il y a un autre guide
très compréhensible.
Comment penser
à un tool de CLI?
Comment parler de la history?
Comment parler de la convention
et de la place où ils viennent?
C'est super intéressant de le lire
quand nous pensions
comment structurez le CLI.
Si vous êtes dans un business
de construction, c'est bien
d'avoir le temps.
C'est un skill
de apprendre.
Je fais beaucoup de automations
de la maison.
Et de la temps, vous pouvez créer un CLI
pour vous-même et utiliser ça
dans vos jobs crône.
C'est vrai.
Je dis niche, mais pas niche.
C'est une bonne phrase.
Ce que nous avons trouvé,
c'est qu'il y a un peu de longs tails
où il y a peut-être 10 que tout le monde
utilise.
Mais il y a un grand nombre
où vous pouvez utiliser un CLI
pour tout le monde.
Et tout le monde a un spot
qui trouve les outils que ils font régulièrement.
Il y a beaucoup de tools.
C'est intéressant.
Un CLI tool est le premier
que j'ai jamais écrit.
Et
c'est un moyen
d'y construire
une interface pour un programme
qui est plus facile.
À la base, vous êtes
standardis et standardis.
La première programme de Hello World
est essentiellement
plus ou moins un CLI app.
Je pense que c'est génial
de avoir des guides
pour faire ça bien
et faire une première classe de l'expérience
et ne pas juste dire que
vous êtes en train de faire ces choses.
Je pense que plus de gens peuvent apprendre
comment faire ça
dans un moyen consistant
et mature, le meilleur est
notre whole écosystème.
En continuant,
avec l'automation de la maison,
j'ai ajouté beaucoup de nouveaux devises
à mon maison.
Je m'ai essayé de faire
tout le travail avec Apple HomeKit.
Donc HomeBridge est une plateforme
pour ajouter
d'autres devises à votre homekit.
C'est une communauté
d'open source
où tout ce que vous voulez
intégrer a un plugin
installé par NPM.
Et vous configurez pour vos nécessités.
C'est vraiment incroyable
comment beaucoup de plugins et integrations
sont là. C'est drôle.
Je n'aime pas que les deux meurtres
se débloquent maintenant, mais c'est
un autre truc que vous devez...
Ça fait des problèmes pour les programmers.
Si vos deux meurtres sont débloquées,
quand vous avez un bug.
Ça s'arrête quand vous vous abaissez
votre whole maison,
parce que vous avez débloqué le wrong computer.
C'est un projet de fun.
Je l'ai étudiant
aujourd'hui quand j'ai essayé de trouver
plus de terminaux.
Je suis sûr que vous allez le faire.
C'est un code
pour construire
des interfaces textes
à l'interface de la configuration.
C'est comme si vous avez une spécification
et que ça génère ce truc pour vous.
Ça fait que...
ça fait que c'est un interface texte.
Mais c'est relativement simplif.
Ça vous donne une menu qui est persistante
au bout de votre terminal.
Et vous avez l'output
à l'arrivée et vous pouvez voir
ce que les choses font.
C'est vraiment cool.
En fait, quand j'ai vu ça,
j'ai pensé à FIG
et j'ai pensé à la complète auto.
Ça me fait un projet de fun
de jouer avec.
C'est un format
de complétion.
C'est ce que je pense.
Ok, je peux passer
par la main.
Je pense que
si on ne faisait pas FIG,
si je pouvais choisir
un autre type de shell, je serais
en train de utiliser FISH.
C'est un shell incroyable,
tout le défi est juste super.
C'est à dire que la plupart des utilisateurs
utilisent Zshell.
On utilise les outils que les utilisateurs
travaillent avec.
On peut prendre des bugs et fixer
les outils rapidement.
Mais je veux des fonctionnalités
de FISH en Zshell.
Il y a beaucoup de plugins.
Il y a un que je n'ai pas trouvé
récemment.
Les abréviations.
Un alias
est un rm
de trash.
Si je type rm-rf
et on entre,
il y a un rm en termen.
Mais il est pas possible de l'execuer
si je type trash.
Les abréviations en FISH
changent les commandes
que tu type.
Si je fais un abréviation
en termes de l'espace,
il change la rm-rf
en termes de trash.
C'est super cool.
Je l'utilise pour des choses
comme ls.
Je l'utilise exa.
C'est un bon moyen
de montrer l'outil.
Mais je n'ai jamais
pas eu l'intention d'exer.
Si je vais au autre computer,
je vais toujours en type ls.
Mais je l'aime pas
de savoir que,
plutôt que d'utiliser un alias,
même si je fais ls
avec des outils,
je l'aime de savoir que si je type ls
dans mon termen interactif,
il change et on l'exer.
Je sais que l'exe est,
mais je n'ai pas le temps de le faire.
Mais j'aime de se déterrir
avec des gits.
Je l'aime de voir ce que je type
et de savoir ce que je fais.
Je pense que c'est le meilleur de l'un des deux.
Si vous avez un shortcut,
il s'exprime et vous savez ce que vous faites.
Mais si vous avez un alias,
vous avez oublié il y a des années.
C'est un tout petit set-up.
Et vous utilisez tout le temps.
Tout le temps, je type ls.
Les abrégations sont amusantes.
C'est l'une des meilleurs features.
J'ai un fil d'abrégation.
C'est un fil de texte
qui va dans les parces et
qui t'applique.
Mais c'est un bon moyen
d'utiliser un alias
mais d'apprendre un commandement.
Parce que ça explique.
C'est le premier point de la fiche qui a été créé.
Quand je type mes alias
et je sais exactement ce qui se passe.
C'est quelque chose
que beaucoup de gens ont demandé.
C'est un autre de ces touches
où si on se déterrira un peu
en avant, la vie se sent super magique
et intégrée.
On a un brouche.
Je n'ai pas parlé de la maintenance
de ce brouche un peu plus tard.
Pour ceux qui ne peuvent pas
voir la fiche,
le brouche est un browser
qui est un browser texte.
Mais comme les lignes de l'old school
et de Gopher,
c'est un screenshot
de la webview
sur le server.
Et puis les codes de couleur
pour votre terminal.
Vous vous endez avec un browser
sur votre terminal
qui est utilisé pour les codes de code ANZ
mais qui est en fait
une representation assez
précise.
Et Tom, la maintenance
est aussi aussi.
On a beaucoup aimé comment il a fait
ce travail,
il a dit toutes ces choses marquées.
Maintenant, on sait exactement ce que la Internet
et les 80s auraient à l'air.
La dernière pour le jour
de la fiche, la fiche de la fiche
est la fiche que j'ai créée.
Mais la première fois que je suis arrivé
à la fiche,
c'est que
la fiche de la fiche
est la première fois que je suis arrivé
à la fiche.
Et je me suis dit que


à la fiche.
Et je me suis dit que
la fiche de la fiche
était la première fois que je suis arrivé à la fiche.
Et je me suis dit que
c'était une espèce d'existence
et vous pouvez utiliser tout le loquage.
C'est très bien.
C'est génial. Vous devez
garder votre quai, le design de la fiche
que vous avez créée.
Alors, la dernière fiche de la fiche
de la fiche
est ce projet.
C'est le Plupi Mini
Trackball.
C'est un nom de la fiche
d'open source,
mais il y a un kit qui se trouve
à la fiche.
C'est un kit d'open source
qui est un firmware.
C'est intéressant que ça se trouve à la fiche,
mais c'est un source à l'open source.
Vous pouvez techniquement construire
ceci de scratch et changer
tout le code et faire tout ce que vous voulez.
Je suis un love trackball et il n'y a pas
beaucoup de bons trackballs.
Et je suis aussi
construitre des choses.
C'est un projet très excitant.
Je vais essayer de le faire
et faire des trucs spéciales
et construire mes propres.
Je l'ai entendu
construire leurs propres keyboards, mais pas de
construire leur propre mouse.
C'est un premier pour moi.
Si vous regardez
leur PCB, c'est vraiment
très clé, parce qu'ils ont
cette fiche de wave
où le PCB
s'est oscillé, donc c'est flexible.
Le board est flexible, donc ne t'en fais pas plus.
Je ne sais pas.
C'est un projet très cool.
Si vous voulez
acheter la whole kit, vous pouvez le faire.
Vous pouvez acheter tout ça en USD canadien,
donc vous faites la translation dans votre tête.
Si ce n'est pas un adulte Lego, je ne sais pas.
MDX est
incroyable. Je pense que quand on parle
de tout ce que vous avez fait,
les processus
et les choses que vous avez automatisées
en vous donnant documentation
pour l'automation, on pense que tout vous
besoin est des éléments formaux.
Et la possibilité
d'y construire
les réactions réactives
dans un simple breakdown, c'est
comme, je ne dois pas être type
un header ou un H1 ou H2
je veux utiliser le format breakdown, mais
si je veux faire quelque chose plus compliqué,
je ne veux pas convertir tout ça en html
et faire tout le format.
Le breakdown est fantastique,
et si je veux faire plus, je peux,
mais je n'ai pas besoin.
C'est impressionnant, et je pense
que c'est un peu plus important
d'y construire des apps de FIG
que nous voulons construire.
MDX, avec un library FIG
pour des commandes de chaleur
ou un dropdown de vos files
et des folders,
c'est comme un no brainer,
un superbe moyen de faire quelque chose.
Et pour quelqu'un de construire un app,
comment faire ça, c'est facile et facile
d'y construire un app?
Je pense que MDX est la solution.
J'ai finalisé mon site personnel
et j'ai fait des blogs,
j'ai vraiment envie de
y mettre MDX,
parce que quand vous voulez
faire quelque chose,
plutôt que d'y mettre,
c'est le meilleur app
que vous pouvez faire.
C'est interractant, et vous pouvez jouer avec des choses.
Je ne fais pas ça
pour que je puisse faire un bon app
C'est comme une interaction,
je pense que c'est un des 10 fois plus
plus bon, et MDX
fait un app
pour que c'est facile de construire une interaction
dans deux documents,
ou dans des textes,
et je pense que c'est un no brainer.
Plugging the personal website,
What's your domain name, Brendan?
BrendanFolk.com
There is a picture of me,
and my twitter handle.
That's it.
And then it says blog coming soon.
Thank you next year.
A developer rewriting their personal website
is like the seasons changing.
What's gonna happen around once a year?
No, I never written it, but I never built it before.
Oh wow.
It is very minimal,
but that's what I like.
It's a writer passage.
My tool tip for last week was sharing
my new personal website,
which is also built on next.js,
uses MDX,
and goes by the digital garden philosophy.
And I actually manage it all
through my obsidian notebook.
So I just write it in obsidian,
and then that gets things to my website.
We touched on doc op earlier,
but this is a really cool library,
or actually it's a library written in a bunch of languages,
and really the core of it is a syntax
for defining CLI tools as health text.
So you just write the health text
and ensures that the parser
kind of corresponds to what you've typed out.
And this just means that your documentation
always stays up to date.
It's a cool way to whip up a CLI tool pretty quickly.
I use doc op a lot back in the day.
So when I first got an open source,
I was doing a lot of Python.
And it was the first place.
It was like the first CLI generation tool
that I stumbled upon.
And I think my favorite thing about it
is you really focus a lot on the health text
because that generates everything else.
Yeah, it's fun.
And this was another thing in a similar vein
of going from a CLI tool
to another, a more visual representation,
so similar to the TUI generator
that you showed Justin.
But this, I think, takes a Python script
and then converts it into a GUI.
The design sense of the GUI
maybe leaves something to be imagined,
but I think it's a cool concept of taking CLI interfaces
and providing some more affordances for the user.
Yeah, I think the most successful version
of a GUI for a CLI tool
is probably the Vue CLI.
I know a lot of people really love it
and it seems like a cool place to take programming.
At one point, I tried to make a web-based interface
for auto, the TUI manage,
but it just didn't make too much of a difference.
I didn't realize that Vue had web-based UI.
Yeah, so if you see a CLI, it's really awesome.
You should definitely check that out.
Yeah, I'll look into it later.
This is super cool.
Oh, wow, that's so cool.
Yeah, yeah, it's great.
So it serves up on some local server
to be like a Jupyter notebook or FishConfig
or something like that.
It does all kinds of things.
Yeah, but it outlines all your commands.
It gives you information about your bundle sizes.
You can just click to run things,
see how things are running.
It's pretty good.
The GUI project that you just showed
reminds me...
One of my old coworkers at ArtSea
had actually written this wrapper
that you could put around a CLI
and make it a Slack command.
So you could just take a CLI tool,
point the service at a CLI tool
and then it would automatically make it a Slack command
and run in a sandbox environment.
That was a clever idea.
This notion of building apps on top of CLIs,
I feel like there's a lot to play with there.
Yeah, totally.
The thing about CLI is sort of like APIs
to build something.
Yeah, they are in a way.
Well, I think that about wraps it up
for this week's episode of DevTools FM.
Thanks, Matt and Brendan, for coming on.
It was a lot of fun talking with you.
Thank you for having us.
Thanks for having us.
That's it for this week's episode of DevTools FM.
Be sure to follow us on YouTube
and wherever you consume your podcasts.
Thanks for listening.