Ep. #102, Database Accessibility with Peter Pistorius of Snaplet

Brian Douglas: Welcome to another installment of JAMstack Radio. On the line we've got Peter Pistorius. Peter, how are you doing?

Peter Pistorius: I'm doing really well. How are you doing, Dougie?

Brian: I am doing perfectly fine.

Peter: Is it cool that I call you B Dougie? That's how I know you online.

Brian: That's how most people know me, quite honestly. I was actually having a conversation, had my first in person DevRel professionals drinkup a couple nights ago and met somebody who knew me only as B Dougie on the internet and called me Dougie in person.

My GitHub handle is Dougie, BDougie, so I actually go by that at GitHub as well so professionally people only know me as B Dougie.

Peter: Perfect. If only we could choose our names.

Brian: Yeah, yeah. It is possible, I mean it's what, one piece of paper away to take it to the courthouse.

Peter: That's true. I've had this dream to name myself Egon, after the person from Ghostbusters but I think that might be too nerdy so I'm going to stick with Peter.

Brian: That's amazing. Wow. We're learning so much about each other in the first 30 seconds. But speaking of about each other, I'd love the listeners to know a little bit more about you if they're not familiar. Who is Peter? How would you describe yourself?

Peter: Yeah, so a little bit of a confession. I originally wrote down what I am here, I am the founder of Snaplet, blah, blah, blah, and that seemed really boring and didn't accurately describe who I am. So I Googled how to introduce yourself and found some solid advice, so I'm a programmer who loves programming.

Programing is often described as an exercise in lifelong frustration. It's a series of unknowns followed by an A-Ha Moment and that just constantly repeats itself. I think because of this we spend our time dealing with a form of learned helplessness where we accept annoying things, we gloss over them and carry on because it's not the core focus of our jobs, which is to write features and fix bugs.

So the last few years I've spent trying to decouple myself from accepting those painful things, and actively trying to make things better for other programmers. How I got here? I was born in South Africa, I spent a ton of time on ROC as a teenager where I got into FreeBSD and I wanted to become a Berkeley computer wizard. I was not cool in school, as you might be able to tell.

Brian: Yeah, I mean I definitely didn't even know what Berkeley, I didn't know anything about California growing up so that's amazing. Why Berkeley? Do you read books or something like that on Silicon Valley and stuff like that?

Peter: So FreeBSD came from Berkeley and at the time there was a whole bunch of lore about these wizards of Berkeley and all the amazing things they were doing with computers. For me it was just an interesting culture and I wanted to be a part of that, but I was super far away and I just gobbled up as much of Silicon Valley culture as I could through the internet.

I never ended up in California, I ended up in Berlin where the cofounders of GitHub started a company called Chatterbug, and I figured that joining them would be the second best thing and it was. I really loved working with Tom and Scott. That's a little bit of my personal journey.

Brian: Cool. How did you run into them? Well, I guess you were living in Berlin, but what's the origin story of that?

Peter: So I found a job posting and I applied, but I applied really, really aggressively. I created a demo and I sent it to them and I eventually got an interview with Scott and I met him and we spoke. I went through like three or four series of interviews and I just got the job.

I was a React Native developer and I think they were looking for someone like that. I suppose it was just luck, and I think a lot of my career has actually been luck. I've just fallen into programming, I've fallen into interesting roles in interesting projects and I fell into my job at Chatterbug. I wanted it and I worked to try and make that happen, but it was the right time at the right place.

Brian: Yeah. You say luck, but you obviously were already ingrained into the community and even NRSE and stuff like that. Did you know who Scott and Tom were when you applied for the job?

Peter: Yeah, I think they actually advertised it as work with the co-founders of GitHub, so I was like, "Damn, yeah."

Brian: Okay, that's a good selling point. Yeah.

Peter: "I definitely want to do that."

Brian: Yeah, so you ended up working at Chatterbug, which Chatterbug is still around, still going strong. It's funny because off air I was saying, "I've never met Scott before but I know a lot about him because I work at GitHub and I work with people who knew him and personally worked with him."

But yeah, he likes learning languages so they have a product to help people learn languages, and I'm not going to sell Chatterbug very well on this podcast. But basically you started working there but you also started working on this little side project called Redwood.JS too as well. Do you want to share about what that is and how you got involved there?

Peter: Yeah. So whilst I was working at Chatterbug, I worked with Tom on the React Native Happen, the front end, and we started discovering patterns that made building a React project feel good. But back then there amount of integration that you had to code was insane, if you wanted to use React you had to use Wetback, and if you wanted to use Storybook there was integrations there. There was JS, there was integrations there.

You just needed to join all these tools together and it was insane, so we thought we could help by giving those tools as standards out of the box.

Really how it happened was one night I was lying in bed and Tom sent me a message on Slack and he said, "Hey, I'm thinking about building the things that we've been doing into a framework. Would you be interested?" And I think I literally jumped out of bed and I was fistbumping in the air and my partner was like, "What is going on? What's happening here?" But to me it kind of felt like validation, like this person, Tom, who has such a good reputation, he asked me to build something with him. I poured a ton of myself into Redwood, but it's always been a collaborative effort, I think.

Brian: Yeah, yeah. Awesome. What I wanted to talk about today is Snaplet, so you're now working on this new problem which I guess... What is Snaplet and what problem is it solving?

Peter: Yeah, so Snaplet is a tool that gives developers access to accurate data during development. So what does that mean? If you're a developer and you code against a development database, that's to say the code for the feature that you're currently writing or the bug that you're currently fixing communicates with your development database.

The data inside of that database is often not great because it's an inaccurate representation of production and it probably has a bunch of weird rows of modifications compared to everyone else on your team. So the state, your database, is just inaccurate. This is bad because your code will be shipped to production and run against the production database, but a bunch of your own assumptions whilst you were writing the feature or fixing the bug are just inaccurate.

So Snaplet aims to solve that by giving you tools to code against a database that looks like your actual production database, but without the private information. If you think about it, you want to build features or fix bugs and write tests that reflect reality, and creating a seed script isn't part of any of that work. It's just adjacent to the goals you're trying to achieve as a developer. So I want to take that way and just give you really accurate data that you can code against and just focus on your job.

Brian: Okay, cool. So being able to see data and also you mentioned the representation of being able to not have private information. Is this like seeding data but also like a faker type tool built in together?

Peter: Yeah. So how it works is we connect to your database and we copy the rows out of your database and transform them based on a configuration that you give us. So you'll tell us, as an example you'll asy, "We have a Users table and there's an email column in the Users table. So replace those with fake emails." And you can do that for anything, you can do it for names, first names, and right now we have a DSL so you use these strings in order to represent how you want us to manipulate your data.

But we're going to give you a JavaScript callback so you can actually write functions and have more control over how the data is represented. We then copy that data to disk where you can then restore it using our CLI onto your local machine, onto a staging database or a developer database in the cloud, or even a container.

Brian: Okay, cool. Then I guess my question is why has no one else thought of this? I can't think of any other tool that's very similar to being able to take a snapshot of production stuff, update records so that way folks can have access to real looking data. Other than Faker, like the Faker libraries, the suite tools, that's the closest I've seen. But that's also open source libraries and not quite the same. I assume you were doing this at Chatterbug first before you jumped over to do this full time?

Peter: Actually at Chatterbug for the longest time, we had just a direct dump of production and that's what happens in a lot of companies. You just get this, "Here you go, you can copy down the production dump and don't lose your laptop, or if you do, make sure your drive is encrypted so that we don't lose this data." But I think intuitively, as developers, we really care about privacy and then you're carrying around peoples' private data.

You can't show demos of the product or features that might leak that information and you just don't want that. So eventually we had a script that did transform some of the data but it did it poorly and it was a lot of work. So yeah, that was really part of the origin of this. It was like I want to self serve for my needs as a developer, I want to be able to get access to data when I need it and reset the snapshot or get a new one every day.

Because often what happen is someone else in your organization is taking care of the snapshots of your database, and when they break, no one else has visibility into whether they broke or when they broke or how to fix them, and that person could be on holiday and you need a production dump now, and you just can't get it. You have to nag some person who's in a different timezone and wait for them to come back and be like, "Hey, can I actually get access to the data? I need it now." So I wanted to serve every individual's needs on the team or every programmer's needs on the team, so that they can just do it for themselves.

Brian: Okay. That's amazing too, as well. So you're now working at Snaplet. How is it going? At what point is the stage of this project right now? So you're working on this on your own or do you have a team that you're working with?

Peter: Yeah, we're a team, right now we're in open beta. We're a team of eight people, two amazing designers and a couple of developers. Right now we have the ability to create snapshots of your database that is hosted in our own infrastructure but we want to give people the ability to do this on their own machines, so not have to give us access to their production database. I'm very aware that I actually don't want to connect to other people's databases, and even see their data in a transformed fashion.

So we want to make that open to the public, we want to make a lot of it open source, we want to add new methods of transforming your data, the ability to generate data, the ability to subset data and introduce new ways of handling transformations. So we really want to make this a tool for the community so that developers can manage their own data requirements on their own terms.

Brian: Okay, cool. So I'm ready to use it today, because I had mentioned offline that I was working on a project. Actually, I'm working on this project, Open Sauce, and we have a snapshot of data that we've essentially scraped from GitHub, we also get some realtime data as well. Open Sauced is a project to find your next open source contribution. Sorry, I'm going into pitch mode. Then we have a list of usernames and stars for repos and issues and forks and stuff like that. So that data exists and we don't store things like emails, so that's not an issue for us.

But the problem is that we have so much data and some dat actually hits GitHub's API publicly sometimes. Things like images, we haven't really started caching those yet. So that's something that we kind of need to fake when we're testing, because if we're seeing how much stuff we can render on the page and we end up refreshing 10 times in an hour, that's definitely a way to get rate limited. So I'm curious, can I provide some sort of random seed of images to be able to do that locally and not have to get rate limited every time I try to make a new feature?

Peter: Totally. Yeah, you could replace those columns. Is it stored in a JSON object or is it a column?

Brian: So right now it's a Postgres database, we're not storing in any way locally. But we're fetching the username and then we hit the API at GitHub.com/profileimage-whatever their URL is, and then it fetches it live. So we did cache it eventually, but my thought is that if I start storing those in a database I probably want to be able to fake that because I don't want to have a bunch of real images that are just bogging down the experience for anybody developing.

Peter: Yeah, so you could get a transformation that replaces that column with some values that you define, either just a static one or a random set of them and then we'll insert those into the table whilst we're creating the snapshot, and you'll have that fake data to work against. You could even kick out those usernames if you didn't want them, if there were any sensitive issues around that.

Brian: Yeah, no issues, but I could see how there would be issues if we start getting more intensive data. We'll eventually get to this point where we'll have way more research and way more logic on how projects work. So I'm curious, as I mentioned, I'm using Supabase. I didn't mention that on air but I mentioned it before we hit live, so I'm using Supabase, it's a Postgres database. I'm leveraging the Supabase SDK and I have Supabase Studio for local instances but it's still looking at production type data. So today with Snaplet, how do I start getting snapshots of my current situation today?

Peter: So your Supabase database, is this hosted locally or is it hosted in Supabase's cloud?

Brian: So technically it's hosted in Supabase's cloud for production, we do have a version that if someone wanted to get local versions they could write a script and then Supabase will work locally. We've had some issues development wise, so technically today it doesn't work. But in the future, someone should be able to clone the repo or fork the repo hopefully, if they're going to contribute, and then write a script to get a snapshot of production data locally with Supabase.

Peter: So this is how I would approach it, I would sign up to Snaplet, I'd connect my production database to Snaplet, I'd create some transformations so that that data that you didn't want hitting the APIs is transformed. Then I'd create a schedule so that I get a snapshot every day or every week or something like that, so that it stays up to date without you having to click a button or something like that.

We contribute the Snaplet config to your code base, that means that anyone who forks that also has access to your project, which means that if they had a token or they're invited to your team, they can restore that snapshot either to their local computer. Or if they had a Supabase instance in the cloud, like a development instance, they could restore it to there.

So you have two options, use that Docker image that Supabase provides for you and restore to that or use an instance in the cloud and restore it to that. Then you've got something you can code against that has accurate data.

Actually this is part of my dream, is that open source projects adopt Snaplet and it becomes the defacto way to share data with those people. And when people move from team to team, they are just accepting that Snaplet is going to be a part of their stack and part of the way that they think about coding against accurate data.

Brian: Yeah. I don't know if you're connected with the Prisma folks, but it's very similar, where it's almost a given if I want to do some ORM type lookups and stuff like that, or even update my Schema. Well, I guess Redwood uses Prisma so you're very familiar with Prisma. But I guess what I'm looking at is, yeah, I totally get this. This is a great addition to a developer workflow, and then I also totally understand too as well. So if I have a Postgres URL, I can point that directly to Snaplet, Snaplet now, is it giving me back a Postgres URL so if it's local I can switch to Snaplet and when it's production I can just use a production one?

Peter: So what it's doing, your development credentials don't change, your production credentials already point to your production Supabase database. So what Snaplet is doing is taking that copy of the production database and you're also giving it credentials of where it should restore it to. So you're coding against this local database and Snaplet will put the data into there so when you're coding, it has that new, refreshed data in it. Just to roll back a little bit with Prisma.

Prisma, we actually have a decent integration to Prisma itself where they bring the structure. You run PrismaMigrateDev and it creates this table structure, and then there is this opportunity to see data. But Snaplet has a data only mode, so you can type SnapletRestore--DataOnly and it won't bring any structure to your local database. It will only insert the data that you've snapshotted so you can use Prisma and Snaplet together quite well.

Brian: Okay. Excellent, yeah. That makes a ton of sense too as well. I could see Snaplet being a plugin or an add on for Supabase or Planet Scale or another hosting platform. I guess there's a lot of tools out there. My question to you now, is this Postgres specific? Is this Node, SQL? We actually like those types of details.

Peter: So right now we're Postgres only, we're trying to focus on satisfying the needs of Postgres users to begin with. But architecturally speaking, we could support any database, we just don't want to go too wide first. Turns out databases are complicated internally, a lot of weird stuff going on in there that isn't very intuitive when you're starting out fresh.

Brian: Yeah, for sure. I mean, I'm excited. I made a prediction last year around the evolution of developer databases and how to approach it, because there was a trend that I was seeing of these... So obviously you have Cockroach, who is huge. Then you've got Hasura who's also at this point huge. Then the tools like Prisma. I see tooling and databases the same way we saw the frontend tooling just completely change where you're no longer just uploading HTML files to S3. Now we have Netlify or Vercel and we have Render.com, and we have all these tools that basically get our sites up and running. I think we're seeing the same thing in databases.

Peter: Yeah, absolutely. I think we as developers, we ignore the fact that a database is more than just reading and writing and structure, and a lot of companies are starting to expose that to us. Like Supabase has this amazing product on top of Postgres, which is amazing, low level access and realtime and all kinds of great stuff and it's just built on top of the database. So I 100% agree with you, super exciting, and that's where I want to be.

I want to be adjacent to all those really great database services and I want to provide data to developers wherever they're working, whether you're working locally or in the cloud, I want to give you the ability to manipulate data in bulk for your own needs.

Brian: Yeah, it's exciting. What's also exciting is I signed up while we were talking.

Peter: Awesome.

Brian: So hopefully other people have also signed up at this point, because I need to see how this thing is going to improve my developer workflow. Not just for me, because I also mentioned I have an open source project, Open Sauced is open source, so I have this weird balance of I want to solve problems in the open and in public, but then I also have the challenge of I've got to make sure it's a reproducible experience for anybody who's driving by and wants to manipulate a weird thing in the dashboard. They can see everything I can see, but also what every other user can see, and that reproducibility is a thing that it can be challenging. Especially if you're storing sensitive stuff, which is why I don't store any sensitive things because I haven't quite figured out that part yet. But yeah, you were saying?

Peter: I was saying I totally get that. I think from one of the things that I really appreciate about Snaplet is that we're dog fooding it, and any new developer that joins our team, they literally type one command, Snaplet Restore, and then they have a really accurate version of our production database. So whenever we see a bug in production or when we have to code a feature that has to code against a lot of rows or things like that, we don't have this disconnect between what the reality and what you're coding against. It's a much nicer experience than having to find some AWS keys, run some random seed script that then inserts it into your database. The experience is really polished, I think, and it would be similar for your users of Open Sauced. They just need to type Snaplet Restore in the CLI and they'll get a production like database.

Brian: Yeah, yeah. I love this because all these Postgres adjacent tools, which I agree with the choice of making sure it works with Postgres because you get a large swathe of engineers to work with and entice them to leverage your product. But yeah, the Postgres tooling is in the back of my head now because I've done so much work with my current database, a command like Snaplet Restore makes sense to me. That way I can just have a really quick scrape of folks, "Hey, make sure you hit NPM install, make sure you hit Snaplet Restore and then now you're off to the races."

Go change whatever you need to do or pick up a feature or what not. I live and die based on how easy it is for people to contribute to my project, because again, working in the open, it's not a very hands on sort of developer tool. There's a sense of like a CLI tool or even like a Snaplet, but it's got a UI in front of it so I get a bunch of folks who are approaching contributing because I do a lot of React stuff, a lot of UI stuff. But then trying to educate folks who want to make UI changes on how to run scripts and pSQL stuff to make it work for their situation, that's where most people just drop off. So I'm trying to make sure, no matter who walks into my project, and I think Snaplet is a really good choice for getting things started.

Peter: Actually I think one of the things that we really brought to the table when we were starting Redwood.JS was we wanted to bond with the community and in the beginning it was just Tom, Rob and myself and then later on, David. But we really wanted other people to contribute and I think that's one of the big strengths of Redwood.JS is that we spent a lot of time building contributor tools and they work really well. And we do see a lot of contributions from varying degrees of people in the community, so I 100% appreciate that and I will personally contribute some Snaplet love to Open Sauced to see if that works for you.

Brian: Okay, cool. Yeah, I'm literally at the page where I drop in my connection strings, so I will definitely kick the tires on this later this afternoon. We've been talking about Snaplet before this interview, so my top contributor is already prepared because we tried to solve this problem already and had to back out of it because it was just too convoluted for new contributors. So yeah, if y'all can keep up with that promise, you definitely got a user and potentially a customer. I don't know when y'all have pricing, or I guess there's no pricing today, right?

Peter: No, no. It's completely free. What we're trying to do is build the best product for individuals and once we get to teams or bigger companies, we'll start thinking about pricing. But right now we're really trying to service the market and make sure that developers are happy with the product that we're building. You said that you were going to enter your connection string in there, but we have a demo one you can try out which is actually a Supabase database. You can just copy that and paste it and play around. You don't have to give us your production credentials, and we're very near to the point where you don't have to give that to us at all. You can just run this yourself in your own infrastructure, create a snapshot on the file system and restore from that same one on the file system.

Brian: Ah, that's even better. Yeah, because basically now I'm even getting into this even more now, because I can just tell you what the rows and the records look like, which is exactly what you said earlier, which is why you give us a test one. Absolutely amazing, and amazing onboarding flow. The fact that I can fumble around and click through this and get to this revelation, forget webinars. Y'all can just literally have people click login and then you've got something you can copy and paste, yeah?

Peter: Thank you. Awesome. I actually had a person in mind when I was building this, and it's a junior developer that I met at Chatterbug and I built this for her in particular.

She wanted to learn how to code, and she didn't want to learn about all this other stuff. She had real goals, which was writing features and fixing bugs, and these other things just distracted her and made her feel anxious.

So I want to give people that ability just to focus on what it is you're here to do, the other stuff can come later over time. So yeah, I want people to self service their needs, that's the goal here.

Brian: Yeah, that makes so much sense. That's an awesome story too, as well. Because I think a lot of folks, sometimes we can approach tooling, especially developer tooling in the sense of, "I need senior engineers to opt in because I need to sell to enterprises."Or whatever the goal is, but to be able to approach it in a way that it can actually bring in junior developers without needing to know what PSQL is.

That's genius because you're going to get way more of an adoption, of folks who can prove this working, and it's something actually, inside baseball, but we discovered at Nullify, is that most people... The rebuttal for not using Nullify was, "I already use S3 and I already manage my own CDN out of my kitchen. Why would I use Nullify?" And it's like, "Well, maybe you're not the right person for this then."

So I ended up doing dev rail as an engineer at Nullify and the thing I did actually was every time I went to a conference, I spoke at a boot camp for that same reason, because I could actually get a bunch of boot camp students who are like, "Oh, I can get a blog up without knowing AWS and how to do all this stuff?" Yeah. At the time, the industry was like... we were very much knees deep in, "No, you need to know devops and AWS and be able to manage CSS and React components and stuff like that." And I was like, "I don't know if that's the way we're heading towards."

Peter: Yeah, absolutely. I think the philosophy of attention in larger organizations, of if you join a company and there are these clear distinctions between devops and developers, you have to sit and wait for things that is infrastructure. You're like, "Hey, I need somewhere to upload some files to or I need that database dump, or I need to see what going on in production," and you have to wait. Really what we want to do is give people the tools to make sure that they're successful without having to go through other people.

Brian: Cool. Well, appreciate you chatting with us about Snaplet. Again, I'm sold, even though it's a free product today. And definitely going to be kicking around with this little connection string. Again, check out Snaplet and for now we're going to roll over into the picks. These are Jam Picks, anything you're jamming on, could be music, food. Honesty, just about anything. But today I only have technology picks, which is not like myself, but I'm writing tons of code right now so it's currently what I'm jamming on right now. So if you don't mind, I'll go first, Peter.

Peter: Go for it.

Brian: My first pick is Radix, maybe it's Radix, but R-A-D-I-X. It's a UI library for a lot of these small components within the web, so menus and dialog boxes and really... I don't know. The tool chest of things you have to build all the time, but can also be super tedious. Things like radio buttons, how do you do that in React? There's so many different ways to do it, and what I like about Radix is that it solves a problem and it solves it really, really elegantly and really fast.

No longer are you trying to figure out, "If I click this button, what happens? And that button, what happens?" Or tabs, lists and stuff like that. We're doing an overhaul on the Open Sauced design system, we've got disjointed parts, we've got a design system I built six years ago when I was at Nullify. Open Sauce actually looks just like Nullify six years ago and has never been updated because Nullify's been updated multiple times since then.

Basically what I'm getting at is we need to be a little more nimble and be able to update the design system, so making that decision was actually really good to get that out of the way, and then now we're polishing and trying to get a consistent UI look. So there's a lot of plugins Tailwind Radix or other types of Radix combinations for styling, and what I've found with picking a design system, having the styling separate helps me have flexibility because the things that I don't want to build is the radio buttons, but I do want to have control on the actual design itself.

That's a decision we've made so far, and looking forward to plugging along. I feel like I got to take a Saturday or something like that to finish all these components or go pay a programmer or somebody who's interested in doing some UI stuff with me. But hopefully we'll be working on this too. But we didn't even address the great design of Snaplet. You mentioned you had two designers, I just wanted to shout out how nice the design looks.

Peter: Thanks. Two of the designers are my partner and her twin sister. Like I mentioned luck earlier, I'm one of the luckiest people, I think on the planet, because they push and stretch me every day with the things that they bring out. I don't know if you saw, we actually created a cereal box that shares our company values and it was one of the most creative things I've ever seen. They're not developers, they're just creative people, but the language that they used was just so amazing.

Brian: That is awesome.

Peter: Yeah, I'm very lucky. I came about it by we were sitting, eating breakfast and I had bought some cereal while I was in South Africa and I was reading the box, and the copy was terrible. But I couldn't stop reading the box, and then I thought actually it would be a really good idea to share our company values on something that you can't stop reading. You're just sitting there and you're like, "All right, I'm going to entertain myself with this stuff." And you read it like six or seven times and then the box is done and you throw it away.

Brian: Yeah, can you send that link? I'd love to take a look at that. Then while you're rapping that link, I want to mention my other pick real quick. I've been actually using Nullify Bridge deploys for my beta, so all the UI changes that we're making, we're testing them in production, but the way Nullify works, because we're using Nullify for the hosting, is that you can actually deploy directly to a branch.

Our branch is called Beta, and the site itself is called Hot.OpenSauce.Pizza, so with branch deploys you can deploy the branch but you can also set it to a custom domain, so we now have Beta.Hot.OpenSauce.Pizza, and it just works really elegantly. So instead of shipping stuff live and breaking stuff, shipping fast and breaking things, we can now do that on an entire custom domain.

Then it's a lot easier to entice people to test things when you have it live in production, as opposed to, "Here's the PR. Click on the Deploy Preview link and then we'll keep you updated." No. It's, "URL has been updated. Go test it. Let me know if it works for you."And our first integration with Radix is actually now live.

Well, by the time you get to this podcast it'll be a completely different beta version, but what I'm getting at is we're now testing out some cool things and UI stuff in basically production, because it mirrors production today. So I could see if we wanted to do some interesting things with Snaplet on the beta flag instead of using Production database, I think we could actually do something pretty clever there as well. So we'll chat.

Peter: Yes, I was going to jump in there and be like, "Snaplet can help you here. Let's do this."

Brian: Awesome. Yeah, for things like testing pagination or infinite scrolling, I want to test that before going live in production so I would totally just generate a ton of Snaplet data and then test that without needing to hit the production stuff.

Peter: Awesome.

Brian: Cool. Did you have some picks that you wanted to share as well?

Peter: Yeah. I am lately very interested in databases and one of the ones that I am a fan of is one called HDB, which is kind of like this proxy in front of Postgres, but it abstracts a way SQL, the schema, data fetching and things like that, you communicate through this proxy and it's just really incredibly elegant I think.

So like with Prisma where you define the schema model, you can do the same thing in HDB but it creates a graph of relations and the schema language is really awesome compared to SQL. Let me put it that way. It feels incredibly powerful and it's like the database reimagined for today, and I could imagine if I were starting a new project that I would want to try this out. As an open source developer, I would try this as something that's interesting and see how it works in production.

Brian: Cool, yeah. I'm checking it out right now. I want to say I've heard of this, but I don't think I actually took a look into it.

Peter: I think they reached one point a couple of weeks ago and it was in Hacker News and Hacker News was resoundingly positive about their SQL alternative or their query language, which I think is rare.

Brian: Yeah, I think that Hacker News is actually where I saw this come through. Yeah. Very cool. I tried a ton of stuff, I'm a big fan of just jumping on Stream, trying a thing in front of people. I do it in this weird, mob programming experience where we can unblock each other and try to do some tutorial or whatnot.

Peter: You don't get mob fingers where you literally can't type anymore? That happens to me all the time when I'm demoing or trying to code in front of people.

Brian: No, I don't know that that's actually happened to me. But I do get brain farts, lots of brain farts, but that's what I like about having the mob programming experience, is being able to have people unblock me and be like, "Actually you were going to type this." And you're like, "Oh yeah, you're right. Okay, let's keep going."

Peter: Yeah, it's collaborative debugging. Everyone needs that sometimes, unless it's unhelpful. So my second pick is an app called Centered, Centered.app. I think one of the things that I really appreciate about being a programmer is that you spend a lot of your time in flow, if you can get there, and Centered is an app that helps you get to flow using three mechanisms. One is a Pomodoro timer, which is like a 25 minute timer and a 5 minute break. The other is it plays music in your ear, and the third part is... Well, I guess there's four parts.

The third part is that is puts you into a collaborative experience with other people who are trying to get into flow and you can see them doing their work. You can share your camera and show your face, you don't have to do that. I think that's a little weird, but other people do, and you're like, "Okay, there are other people working in the world, I'm joining them."

The fourth part is you create a list of things that you should do and every task gets 25 minutes so you can break up your work into steps, and it's like a formulaic way of getting into flow. Now that I'm a founder, I don't think I ever get into flow because I'm pulled into a million directions but when I want to think for an extended period of time, I used Centered and I really like it.

Brian: Yeah, nice. For sure. I've actually seen Centered around the Twitterverse. I haven't actually checked it out, but I know the creator-founder, Eric, from Twitter as well. He has a very fun Twitter account to follow to as well.

Peter: Yeah. The last one that I really have fallen in love with is an app called Warp.dev. It's a terminal that's written in Rust and it supercharges your development abilities. So your terminal is usually just this long stream out output and input, but it isn't really structured so it's difficult to figure out what you were trying to do when there's so much text on your screen. Warp segments your commands into these blocks and it gives you a neat way to input things, it just feels like the terminal reimagined for today, and it's fast.

Brian: Yeah, I did actually use this very recently as well. They're actually hiring right now, so folks, definitely reach out to Warp if you want a job. But yeah, I really enjoyed the experience. I actually have it on my focus development machine, so I'm talking to you on my work machine but then I have a development machine and I've actually used it a couple of times and it's pretty nice.

Peter: I saw you unboxed the M1 the other day. Is that your dev machine?

Brian: No, that's my work machine. I still use a 2017 MacBook Pro. It's the six months before the touchbar, so it's the last one they put out.

Peter: Does it have the good keyboard or the bad keyboard?

Brian: It's the good keyboard. Yeah, so it's the last model with the good keyboard.

Peter: I actually owe Apple for helping me come up with Snaplet, because what happened was I gave my really powerful laptop back to Chatterbug when I stopped working there and I went back to my 2015 MacBook Pro, the one that had the good keyboard. I didn't want to buy a new one because the keyboards were so terrible, but that computer was super slow. I was coding locally, and I was like, "No, I need code in the cloud because this thing's too slow." And then I would boot up a new VM every time I wanted to create a new PR, but I didn't have a database, but I had this production database.

So I was like, "How am I going to get this data onto this local dev machine?" And then I started tinkering with that, like you were doing for Open Sauced, and I was like, "If this is a problem for me, and it's a lot of work, I could just imagine how I could make this good for other people too." So thank you, Apple, for those terrible keyboards.

Brian: Yeah, for sure. I have a slew of content about setting up a new dev machine because it's been four years since I've had to do that, and there's all these new things that are out there like Warp and Fig. So I've been trying to try a bunch of stuff as I'm building the best dev environment. It's been a while, because I'm a VM user and I've never got out of Bash, so I've been out of inertia, never try anything new, and now I'm trying everything.

Peter: Yeah. Are you using VS Code?

Brian: I am using VS Code because now I'm at the point where all the typescript, type ahead stuff and everything else, I'm just stuck. So a couple of VM based IDs that are built on top of VS Code stuff, I've tried those and those are pretty good, like OmniVM. But I still go back to VS Code because I just need all the latest and greatest now, I'm just stuck there.

Peter: Yeah, it's interesting. I always think that text editors are one of those things that people stick with for a long time, but in my career I've seen like three or four industry shifts to different ones. And VS Code is the latest one, and I'm wondering if there will be another one. Who knows?

Brian: I mean, if things like Warp.Dev are changing the way we look at the terminal, I think there's opportunity for new stuff. But yeah, I think it's just how willing or able are you to shift? This is my problem, I shift development changes very rarely. If I know something is working or if I have a setup or a dot file that works, I'm not changing it because I need inertia. I just need to jump in, make a change, which is why I go through so much design system work, because I want to be able to have stuff I can pull off the shelf and just throw on the page.

Peter: Totally.

Brian: All right, yeah. Peter, thanks so much for the conversation. I think we should definitely keep in touch.

Peter: Yeah, thanks, Brian.

Brian: And listeners, keep spreading the Jam.