Speaker 1: Hey, folks, welcome back to another episode of JavaScript Jabber.
Speaker 1: This week, on our panel, we have Steve Edwards.
Speaker 2: Yo yo yo, coming at you from away too warm Portland.
Speaker 1: I'm Charles Maxwood from Top End devs. Well, I'm too
Speaker 1: far west for that big cold storm. But it's still
Speaker 1: cold here.
Speaker 2: It's maybe too warm. Man. Our snowpack sucks. Yeah, been
Speaker 2: able to get any skiing is just awful.
Speaker 1: Yeah, same here. People are worried about water. I live
Speaker 1: in Utah. If you're not aware, we have a special
Speaker 1: guest though this week. That is Valeri Karpov. Do you
Speaker 1: want to introduce yourself. I know we've had you on before,
Speaker 1: but just remind people who you are.
Speaker 3: Yeah, Hi everyone. My name is Belle. I'm the maintainer
Speaker 3: of Mongers. I'm popular ODM for no JS and Mongo dB,
Speaker 3: and I do freelance web development. I'm based in Miami, Florida,
Speaker 3: which is much colder than expected. I had to turn
Speaker 3: on the heat for the first time. I'm telling Chuck,
Speaker 3: first time turning the seats. I moved to Miami about
Speaker 3: seven years ago. That's brutal.
Speaker 1: Yeah, I feel your pain. Yeah, my son's on a
Speaker 1: mission for the church. In South Carolina, and yeah, apparently
Speaker 1: people don't deal well with cold there either, so.
Speaker 3: No, not used to it. I mean, yeah, I have
Speaker 3: never seen Miami. I haven't seen Miami break into the
Speaker 3: thirties before since it's been a while.
Speaker 1: Yeah, I was accused of not teaching him how to
Speaker 1: drive on the ice, which I know isn't true. So anyway,
Speaker 1: let's dive in. Let's talk about Mongoose. I'm assuming that
Speaker 1: people have some idea of what it is, and I
Speaker 1: really want to get more into you know, features, functions,
Speaker 1: you know, it seems like a lot more adoption of AI.
Speaker 1: Where does it? Where does mongoos get us from there?
Speaker 1: But just kind of set the stage to get us going,
Speaker 1: like what is mongoose And at a high level what
Speaker 1: does it do for people?
Speaker 3: But a high level, it's like an O R M
Speaker 3: or O D M and no sql land or for
Speaker 3: no jas and malgaib so it provides you like the
Speaker 3: M and MBC or for working with mafugedd B. We
Speaker 3: recently released Mongoose nine, big breaking release, first major release
Speaker 3: that we've had in two years. Got a few a
Speaker 3: few cool new features there, and then we're also working
Speaker 3: on a mungo centric muggedy b gooy called Magus Studio
Speaker 3: that would like to take some time to talk about.
Speaker 3: And then yeah, there's something else that you want to
Speaker 3: talk about. We also are we've been working on a
Speaker 3: kind of a plug in with with the data Stacks team.
Speaker 3: I guess now they're IBM that what's mongoose talked to
Speaker 3: a patche Cassandra via Data Stacks data API. So those
Speaker 3: are kind of like three topics that I think we
Speaker 3: can discuss related to Magus that are a little bit
Speaker 3: of a little bit newer and a little bit less
Speaker 3: less of the standard mongoose stuff. If you want to
Speaker 3: talk about kind of high level what mongoose isn't one out,
Speaker 3: we can talk about that before we can talk about
Speaker 3: one of the three new things that are going on.
Speaker 1: Yeah, I think like O rms and you know, or
Speaker 1: in this case ODMs, which I'm assuming D stands for
Speaker 1: document instead of relation, are probably pretty well understood, and
Speaker 1: I'm assuming that you provide a lot of the standard
Speaker 1: features you see from other O rms or or like libraries.
Speaker 1: So let's let's dive into the new features and if
Speaker 1: people want to learn more they can go pick up.
Speaker 1: I think we've had you on before to talk about Mongoose,
Speaker 1: and so they can probably go find an older episode
Speaker 1: that gets into the fundamentals of what Mongoose is.
Speaker 3: Yeah. I think I've probably been on JavaScript Chad at
Speaker 3: least work times in the last twelve years, give or take.
Speaker 2: Yeah, we did views on View twice too. I was
Speaker 2: just looking that up.
Speaker 3: Yeah, yeah, I might need to do views on View
Speaker 3: again because Mama's Studio also built a view so that
Speaker 3: could be a fun Oh is it really? Oh cool?
Speaker 2: Yeah, I'm not doing that podcast anymore, but so we
Speaker 2: can talk about it here if you want to. This
Speaker 2: is where we try to squeeze in a little bit
Speaker 2: of view in job the script here.
Speaker 3: Okay, Yeah, that's something we can talk about too. Yeah.
Speaker 3: I pretty much all of my software developed in view
Speaker 3: these days, unless unless I'm working for a client that
Speaker 3: has a strong front end preference. I cool.
Speaker 2: So what's new and exciting in mongoos will now.
Speaker 3: So Mongsteine, it's less about kind of like flashy features
Speaker 3: and more about producing long term friction and specifically to
Speaker 3: type script. I think one of the things one of
Speaker 3: the major changes that we made was before we had it,
Speaker 3: so that's functions like find, which is the general way
Speaker 3: that you execute a query to load some documents. In Mongoose,
Speaker 3: the typescript types there were very permissive and just let
Speaker 3: you pass in whatever you wanted. We for Mongus nine,
Speaker 3: we made that more script and made it so that's okay,
Speaker 3: we have explicitly strong types or for what parameters you
Speaker 3: can pass into a query filter. The advantage there is
Speaker 3: twofold and in one one that helps typeescript catch typos
Speaker 3: and whatnot. And for developers that don't use type script
Speaker 3: very much like me, it helps with autocomplete because before
Speaker 3: the fact that it just gave you the fact that
Speaker 3: the types where just any object goes into find, that
Speaker 3: meant that tools like visual Studio code could figure out,
Speaker 3: like what are the properties that you should autocomplete, So
Speaker 3: now you actually get nice little auto complete drop downs
Speaker 3: or for query filters and the other The other big
Speaker 3: thing that we added was was like full a stinc
Speaker 3: a sink stack traces support in the sense that we
Speaker 3: used we had so longos was originally very callback heavy.
Speaker 3: We introduced promises support in twenty fourteen, twenty fifteen, and
Speaker 3: now in with our last release. Our previous breaking release
Speaker 3: Monkeys eight we got rid of the user facing callback
Speaker 3: support in all but one important case, and Alan Mongus
Speaker 3: nine there's no more user facing callback support. It's all
Speaker 3: a sink a weight, which means you get ACNC stack traces,
Speaker 3: which is great.
Speaker 2: Okay, I'm still trying to wrap my head around this.
Speaker 2: So what do you mean?
Speaker 1: Yeah?
Speaker 2: I understand that. So I'm I'm always big into debugging
Speaker 2: and being able to get you know, traces, or I'm
Speaker 2: more of the breakpoint debugger type of person. Uh, whenever possible.
Speaker 2: So what's an acyinc stack trace as compared to the alternative.
Speaker 3: But if you've worked with stack tracings and JavaScript, you've
Speaker 3: probably seen things like processed next tick and rejection or
Speaker 3: list not on timeouts. Those kind of stack traces where
Speaker 3: you just where the stack trace doesn't show you the
Speaker 3: actual calling code.
Speaker 2: That could be a problem.
Speaker 3: I've gotten gotten probably a few of those, and the
Speaker 3: reason for that is is the asik nature of JavaScript.
Speaker 3: Right when you pass a when you pass a call
Speaker 3: back into like a set time out function, for instance,
Speaker 3: you're losing You're losing your call stack when set time
Speaker 3: out calls the function that the callback function that you
Speaker 3: passed into set time out. You'll if that function throws
Speaker 3: an error, you'll see a stack trace that includes Note internals,
Speaker 3: let say okay, and calling it on timeout, you won't
Speaker 3: see your code that actually called the set timeout. And
Speaker 3: this was especially problematic with the callback based code because
Speaker 3: callback based code, you know, runs a synchronously, right, so
Speaker 3: you don't see the code that actually called whatever function
Speaker 3: is getting the callback, and that may debugging Note apps
Speaker 3: for a very very long time basically made every stack
Speaker 3: trace and industry.
Speaker 2: Yeah, other words, you're getting everything but what you want,
Speaker 2: right and getting and you're not.
Speaker 3: Getting your own code. Oh yeah, with a six stack traces,
Speaker 3: it's pretty sure. Yeah, A six stack traces is like
Speaker 3: a V eight feature, so it also works in Chrome.
Speaker 3: But the idea is that if you're calling a sync
Speaker 3: functions all the way down, even if the actual error
Speaker 3: is a synchrons, you still get the full stack trace
Speaker 3: of the actink functions that you call. So let's say
Speaker 3: you know, you I'm in function I'm in an AC
Speaker 3: function called A. I call an AC function called B,
Speaker 3: which calls an ACC function called C, which has a timeout,
Speaker 3: and then throws an error after five seconds. The stack
Speaker 3: trace for that error will include ABC, it won't include
Speaker 3: any I won't to cleave like the known internals for
Speaker 3: on timeout or whatnot.
Speaker 1: Well that's really handy, Yeah, but there.
Speaker 3: Is you need to You need to make sure you're
Speaker 3: calling ACYNC functions all the way down. So the instant that,
Speaker 3: like somewhere in your internals you start calling something that's
Speaker 3: callback based or call a set time out, you're going
Speaker 3: to lose the A six stack traits and then you're
Speaker 3: back to where you started. So the work of there
Speaker 3: for Mongoose was to get rid of all of our
Speaker 3: callback based internals pain point there was like the one
Speaker 3: of the primary ways that you wrote Mangoose middleware was
Speaker 3: was using callbacks specifically gang like you would say Schema
Speaker 3: dot pre save. You would get a next callback, kind
Speaker 3: of similar to Express middleware, where you would call next
Speaker 3: in order to kick off the next middleware and the chain.
Speaker 3: We had to remove that in order to properly support
Speaker 3: acing stack traces all way through it.
Speaker 1: Gotcha. So is there anything you have to do specifically
Speaker 1: to get this to work? Or you just upgrade to
Speaker 1: Mangouse nine and then you're good to go.
Speaker 3: Yeah, upgrade to Margus nine. Any plugins or middleware that
Speaker 3: uses that use it next needs to be rewritten. Thankfully,
Speaker 3: hopefully that's not too many right now. But yeah, but
Speaker 3: in the age of AI, it's much easier to refactor
Speaker 3: this sort of thing. Yeah, so I'm a little bit more,
Speaker 3: a little bit less concerned. Actually, that was pretty much
Speaker 3: like my first foray into AI code generation a long
Speaker 3: time ago was was refactoring some of Mogus's callback based
Speaker 3: code into put into using a Sika weight. This was probably,
Speaker 3: i want to say, early twenty twenty three. This was
Speaker 3: like before pers or anything where you could easily select
Speaker 3: a bunch of code and pass it into pass into
Speaker 3: open AI. What I did was I I wrote some
Speaker 3: code to basically parse out some of Maugus's test suites
Speaker 3: into individual tests and then would pass those tests one
Speaker 3: by one into open ai is a book API, and
Speaker 3: tell it, tell it to refactor this into into a
Speaker 3: synco weight based code. And even back then it did
Speaker 3: a really good job, got like probably ninety percent of
Speaker 3: the test suite done, and it took me. It was
Speaker 3: a like this whole the whole project of refactoring all
Speaker 3: the tests, like we have thousands of tests, and I
Speaker 3: was working like eight hours a day for several days
Speaker 3: straight trying to read back through all this, and then
Speaker 3: I just was like, I'd even tooled for the piss.
Speaker 3: This is getting insane. So uh yeah, I tried open
Speaker 3: AI and Opening I did a great job. That made
Speaker 3: it a one day project as opposed to a multi
Speaker 3: week project.
Speaker 1: Yep, yeah, I'll have to I have to say that
Speaker 1: I've used some of those same kinds of features for
Speaker 1: a number of things, just just to increase my test
Speaker 1: coverage or hey, you know I need to yeah, rework this,
Speaker 1: or you know, rethink that, or even add a feature,
Speaker 1: and yeah it it does a pretty decent job. Usually
Speaker 1: I have to go in and refine a handful of
Speaker 1: things and I have to look over the code make
Speaker 1: sure I didn't do anything stupid. But it's amazing what
Speaker 1: you can get done with AI these days.
Speaker 3: Yeah, I am the other. A couple of weeks ago,
Speaker 3: I gave a demo of some new map features we
Speaker 3: built in Mongoo Studio, and one of the things that
Speaker 3: I demoed was was the ability to just like, so,
Speaker 3: I have a one of my clients has a region model, right,
Speaker 3: It's a region is like a geopolygon forever defining just
Speaker 3: like a region where they have operations. You draw a
Speaker 3: polygon in a map that represents Dallas, and this kind
Speaker 3: represents the boundary of what the company's operations thinks of
Speaker 3: as Dallas. So creating new regions can be annoying because well,
Speaker 3: you need to figure out a way to get all
Speaker 3: the DFAs on points. But I demoed a way where
Speaker 3: you just lai, like, hey, create a create a region
Speaker 3: representing Boston. And while it didn't do a perfect job,
Speaker 3: Mugus Studio's willing to go into Maungus Studio and drag
Speaker 3: the other urgencies around. But like, yeah, I just like
Speaker 3: basic models already know off the top of their heads,
Speaker 3: like where like the approximate lads to longitude of Boston, Massachusetts,
Speaker 3: or or boise iaho or any pretty much any major city.
Speaker 3: So it makes things, Yeah, a lot of if you
Speaker 3: do a lot of really amazing things or amazing seeming
Speaker 3: things with models there just off the shelf, if you
Speaker 3: let them, and they do give you a good enough
Speaker 3: job to at least get you started.
Speaker 1: Yeah, if you give them a function that'll let them
Speaker 1: talk to the internet too. Sometimes if they don't know
Speaker 1: the answer that they have enough context to go and
Speaker 1: look it up somewhere, and so that that's the other
Speaker 1: piece to that that I found is Okay, here's how
Speaker 1: you here's how you make a call, and it's like, oh, okay,
Speaker 1: so what is mango studio.
Speaker 3: So MUGAs studio is a gooey for magaritib that's a
Speaker 3: little bit more higher level than than a traditional database viewer.
Speaker 3: It's got we're trying to make it one more schema
Speaker 3: a whare in the sense that in magerty B or
Speaker 3: maggityb gooies typically don't have a notion of a schema
Speaker 3: right because doesn't really have schemas by default. But magis
Speaker 3: who do have a schema, and that lets you fill
Speaker 3: in things like autocomplete and auto suggest so like auto
Speaker 3: field names when you're typing in the life or filter
Speaker 3: input for why. We're also adding a bunch of AI
Speaker 3: elements in the sense that you can good concrete example,
Speaker 3: what do you try when you want to create a
Speaker 3: new document in your database. There's like a nice button
Speaker 3: you clip to insert in your document, right, and then
Speaker 3: you get a code input that tells that what you
Speaker 3: enter in. Okay, I'm going to enter get a creative
Speaker 3: documents properties, but that can be a little annoying to
Speaker 3: type out manually. So we also have an AI input
Speaker 3: there where you say, okay, let's let's ask the AI
Speaker 3: to generate a document right there without having to go
Speaker 3: anywhere els And that's kind of how the Boise Idaho
Speaker 3: region example worked, just you know, instead of instead of
Speaker 3: typing out the entire all the details for the Boise
Speaker 3: Idaho region, I just have a quick little AI input
Speaker 3: that already has the context of what the schema definition
Speaker 3: is for this particular document, as well as what the
Speaker 3: user is asking, create me a region with for representing
Speaker 3: plays of Idaho, and then the AI just goes in
Speaker 3: and generates the generates the output, the user confirms or
Speaker 3: rejects and can edit it a little bit extra selves
Speaker 3: looks create. So there's that, and then we're also working
Speaker 3: on things like MCP server. So if you have a
Speaker 3: production deployment, well you'll have an MCP server that you
Speaker 3: can connect Claud too that lets you do have a
Speaker 3: controlled code sandbox access like you can let Claud have
Speaker 3: say read only access to your production data or or
Speaker 3: access to write certain collections but not others. For a
Speaker 3: little bit more security.
Speaker 1: Yeah, that makes sense, I mean, and we're seeing this
Speaker 1: more and more right where people are integrating AI into
Speaker 1: their setup, right, and you know, whether it's taking user input,
Speaker 1: so the user essentially is chatting with the AI system
Speaker 1: or at least giving it some kind of prompt or
Speaker 1: sometimes I've seen folks just basically say the LLM is
Speaker 1: going to do a good enough job if I ask
Speaker 1: it to do this job that I don't actually have
Speaker 1: to write explicit code and cover all the edge cases
Speaker 1: and make sure that it does the thing that I
Speaker 1: needed to do. And so both of those scenarios sound
Speaker 1: really really helpful with something like Mongoose, where you can
Speaker 1: essentially say all right, you know, yeah, here are the
Speaker 1: credentials for getting information from my data or you know,
Speaker 1: here's how you query my data, and then yeah, effectively,
Speaker 1: then it has much better information to go off of
Speaker 1: to solve the particular problems that my system or my
Speaker 1: app is solving.
Speaker 3: Yeah, exactly the longer. In addition to having your STEMA definition,
Speaker 3: we also have access to things like methods and statics
Speaker 3: that you define on your on your models, right, So
Speaker 3: that means that well, Mungas Studio can be aware to
Speaker 3: some extent of how you write your code and how
Speaker 3: your application works. But it's a more application centric or
Speaker 3: developer centric database SCOUI. That's meant that's meant to help
Speaker 3: developers do their jobs and be less kind of DBA centric,
Speaker 3: which I find a lot of whether database scoes to be.
Speaker 1: So does it just send a list of available functions
Speaker 1: to claude when it you know, kind of like MCP,
Speaker 1: or it doesn't have to be MCP. Sometimes you send
Speaker 1: a list of functions.
Speaker 3: So we have so for cases like the like the
Speaker 3: creat input and the chat tab places where we have
Speaker 3: AI inputs in the UI, there we we call we
Speaker 3: call out to either like the Gemini a p I
Speaker 3: and the chat API or prop a KPI, and we
Speaker 3: pull the context like we have a collect or. We
Speaker 3: have internal storage that stores just descriptions of the users models,
Speaker 3: including including the bodies of statics and methods, including STEMA definitions. Okay,
Speaker 3: so that data gets passed over there for the m
Speaker 3: CP server. What we do with the server, uh, well there,
Speaker 3: I think what we passed back is more along the
Speaker 3: line of like a typescript definition of what models are available.
Speaker 1: Right, and then it just comes back and calls into
Speaker 1: whatever it needs in order to do what it needs
Speaker 1: to do.
Speaker 3: Yeah, exactly what the MCP server what we're experimenting with
Speaker 3: is kind of like a code sandbox effectively for the
Speaker 3: for the l l M. So we're so like the
Speaker 3: way that our MP server works is more long the
Speaker 3: lives of here. The MCP tool is here, execute this
Speaker 3: code in your sandbox, right, and the AI just kind
Speaker 3: of gets the context of like this is what's available
Speaker 3: on the sandbox. So that's what we're experimenting with, trying
Speaker 3: to figure out how that can work. The other option
Speaker 3: that we're thinking of is almost like a CLI tool.
Speaker 3: That's something I've been debating on Twitter and to make
Speaker 3: it back myself as to whether whether I go the
Speaker 3: m CP route with the code sandbox, whether I just
Speaker 3: have like a c l I or where the line
Speaker 3: it's a CLI to do stuff.
Speaker 1: Yep makes sense.
Speaker 2: Yeah, I was just going to say, where has I've
Speaker 2: been doing some searching where's the Mango U? I keep
Speaker 2: finding the Mango studio what you call it? Because I
Speaker 2: keep finding studio three T.
Speaker 3: Many planks for on the website is mongoostudio dot app? Yeah?
Speaker 3: All one word.
Speaker 2: Yeah, I keep forgetting about these new TLDs we have.
Speaker 1: Yeah, and this is so is this something that I
Speaker 1: can post on my own? Oh I see in your
Speaker 1: video example on here that it's it's got to dot versell. Yeah,
Speaker 1: so it looks like you can. You can play it
Speaker 1: out to wherever you need.
Speaker 3: Yeah, exactly. We support Brusell Netlify and express right now.
Speaker 3: So if you have a Verseell deployment, yeah, you don't
Speaker 3: even need next j ask them to think of it.
Speaker 3: If you have a versall mangu Studio as a sidecar
Speaker 3: alongside your interesting application, or you can just run Mungu
Speaker 3: studio for local usage and you still get mostly all
Speaker 3: the features. I think a couple of things that are
Speaker 3: missing or we don't support dashboards for local development. All
Speaker 3: we do support have like the basic database you were
Speaker 3: and the chat chat tab is our kind like a
Speaker 3: chat GPT interface for generating for generating scripts that execute
Speaker 3: in the momy studio code sandbox, and I think that one.
Speaker 3: The chat tab also gives addresses like one limitation I've
Speaker 3: seen with MCP which may not be as relevant after
Speaker 3: last week when they announced MCP apps, but before MCP
Speaker 3: apps came out like about a week ago, there was
Speaker 3: no way for MCP to really generate like non trivially.
Speaker 3: Why so, one of the things that I wanted from
Speaker 3: the chat tab from the very beginning is the ability
Speaker 3: to generate scripts or to generate charts and maps from
Speaker 3: from after language. So the ability to say things like,
Speaker 3: give me a chart of users created by day for
Speaker 3: the last two weeks. Being able to do that is
Speaker 3: what the chattab is good at. But MCP did not
Speaker 3: really have any meaningful way to do that up until
Speaker 3: very recent So we're figuring out how to do the
Speaker 3: MSP app side.
Speaker 1: Cool. Yeah, I'm just looking at this and thinking to myself,
Speaker 1: I typically use a relational database, but if I were
Speaker 1: using Mango TIB, I mean, having something like this just
Speaker 1: it makes it easier because you get to the place
Speaker 1: where being able to visualize a lot of this stuff,
Speaker 1: it just it allows you to think about it in
Speaker 1: a different way rather than being stuck in your CLI
Speaker 1: or something.
Speaker 3: Yeah. Absolutely, And you'd be surprised how many times like
Speaker 3: a bug is difficult to spot when you're looking at
Speaker 3: a traditional kind of like rods and tables data. Basically
Speaker 3: the gids that you look at a chart, You're like, oh,
Speaker 3: that's a bug I actually spotted, Like from one of
Speaker 3: my clients, I spotted a bug that was costing them
Speaker 3: thousands of dollars just by together a quick chart I
Speaker 3: look at. I'm like, there's an extreme outlier on this chart.
Speaker 3: What's going on there? And well, yeah, we've never caught that.
Speaker 3: If I had to look at that one charm and
Speaker 3: on that chart you just look at, it's like that's
Speaker 3: squaringly obvious. Thing is wrong there.
Speaker 1: So I was paying you on commission on those bugs, right,
Speaker 1: six thousands of dollars a month. They have to pay
Speaker 1: you ten percent.
Speaker 3: Well, if I caused the bug at the first place.
Speaker 2: So when I was working with Mango on Atlas, so
Speaker 2: I used like a guy called Studio three T. That
Speaker 2: was just what my company used. How does Mango's studio
Speaker 2: different from that? Is it just that it's web based
Speaker 2: versus like a separate app or what's the differences between
Speaker 2: those two.
Speaker 3: A couple of things. Web based is one big thing
Speaker 3: for production deployments. In particular, we like to we like
Speaker 3: to have Mangoo's studio as something that you log into
Speaker 3: through through UH through either Gmail a lot through Get
Speaker 3: Help a lot instead of passing around connection strings. So
Speaker 3: one of the things that we've seen that small medium
Speaker 3: businesses do is like when a new engineer joins and
Speaker 3: you want to give them production database access, we just
Speaker 3: send them like a shared credential or shared connection string
Speaker 3: and slack and then ask them to hook up put
Speaker 3: that connection strain in your studio at threep and that
Speaker 3: can be No, that's a little bit insecure, yeah, Dice, Yeah, yeah.
Speaker 3: What you should do is at least have a share
Speaker 3: or a separate connection strength for each individual developer, so
Speaker 3: you can easily onboard off board people rotate it probably
Speaker 3: once every year at least, but nobody does that because
Speaker 3: it's it's tedious, it's a thankless job. Just everyone finds
Speaker 3: it a union and annoyance. No, but he does it.
Speaker 3: With Mango's studio, we do things a little differently in
Speaker 3: the sense that you deploy, deploy mongke you studio as
Speaker 3: a web application, and then people log in by a
Speaker 3: GitHub or Gmail. So if you onboard or off board someone,
Speaker 3: you offboard someone, they lose access to their they're no
Speaker 3: longer part of your GitHub organization, and they lose access
Speaker 3: to the company email. Then they're automatically removed from Monkey
Speaker 3: studio as well. So those are two big differences, the
Speaker 3: production deployments and the well on the web based side
Speaker 3: of things, Yeah, another big thing is well, uh being
Speaker 3: mongt centric and knowing about your Monkey's schemas gives you
Speaker 3: access to things like schema level autocomplete, where again it
Speaker 3: uh monbu studio knows that your users have a first
Speaker 3: name property studio three T doesn't necessarily know that it
Speaker 3: can infer it from the shape of existing documents, but
Speaker 3: it's it's not going to be one accurate that way.
Speaker 3: Another detail is like, we're trying to make all of
Speaker 3: your studio a little bit more, a little bit more
Speaker 3: higher level. I'm a little bit more developer focused in
Speaker 3: the sense that we want to show data less as
Speaker 3: rose and columns and as plain text and more as
Speaker 3: the data that you want, the data that you actually
Speaker 3: want to see in a useful way. So, for example,
Speaker 3: for things that look like GeoJSON, we actually have the
Speaker 3: ability to show the GeoJSON points as mapps. Nice. So
Speaker 3: if you go into looking a particular at a particular
Speaker 3: document and it has like a geok song polygon or points,
Speaker 3: you can actually click to show that on a map.
Speaker 3: A couple of other visualizations that we're adding is for
Speaker 3: image fields we want to actually visualize or have the
Speaker 3: option to this as an image and then or for
Speaker 3: vector data, that's something that would give you worked out
Speaker 3: pretty cool, and so is showing a projection of the
Speaker 3: of the vector data or at least making it easier
Speaker 3: to visualize a bunch of vectors just in your database.
Speaker 2: You are, so, I'm assuming you can also view the
Speaker 2: data and it's raw format right in your.
Speaker 3: Yeah, the format is the default. But if you but
Speaker 3: if you want to just quickly look at something a
Speaker 3: GJ song data point on a map, click a button,
Speaker 3: don't even have to leave studio, which is nice. Is
Speaker 3: a frequent pain point for for me. I've been working
Speaker 3: with geo Data and mal aib for a long long time.
Speaker 3: Just having that all faked into one database food that's
Speaker 3: been huge. I no longer have to worry about what
Speaker 3: I used to have was I had like a script
Speaker 3: that would take in a would take in latitude longitude
Speaker 3: points and just give me a Google Maps output that
Speaker 3: I could copy for account Google Maps that I could
Speaker 3: copy paste into my grouder to view where this to
Speaker 3: be where this was, or to view where a point was.
Speaker 3: And then for polygons there there was pretty much nothing
Speaker 3: I guess I could generate like a Google Maps does
Speaker 3: have like this static image generators, so that's what I
Speaker 3: would probably use, was I would just take a polygon
Speaker 3: and just generate a Google Maps image from a script.
Speaker 3: But that was an elegant and inconvenience, much easier to
Speaker 3: just I'm already and day. Basically I click a button
Speaker 3: to view on the map again, a nice little leaflet
Speaker 3: map that I can edit drag.
Speaker 2: That was my next question. I was curious to see
Speaker 2: what library you're using to generate your maps. If you're
Speaker 2: not using Google Maps anymore.
Speaker 3: It's Sleep. But for for Google Maps, I was talking
Speaker 3: more about their Google Maps has like this api for
Speaker 3: generating static map images, which is actually really useful.
Speaker 2: Yeah, if you just want like a screenshot of a
Speaker 2: map or a one time view as compared to something
Speaker 2: that you can zoom and pan and that kind of stuff.
Speaker 3: Right, yeah, exactly, or if you wants something that's easier
Speaker 3: to share in a place like Slack that will support
Speaker 3: the whole Google Maps experience. Paying the image it's very important.
Speaker 1: So what's coming next for Mongoose or Mongoose Studio.
Speaker 3: For Mongoose, we're probably going to have one more another
Speaker 3: breaking release this year. We will see about exact timing
Speaker 3: and scope, but it's going to be our Mongoose ten
Speaker 3: release if I want to make sure that there's something
Speaker 3: interesting in there. I just haven't settled on exactly what
Speaker 3: I want, but one thing I want is more of
Speaker 3: a switch towards using proxies internally for change tracking as
Speaker 3: opposed to project of defined property, kind of going more
Speaker 3: along the lines of how View does change tracking, whether
Speaker 3: how Magos does change tracking. Now I was gonna say,
Speaker 3: like views, Yeah, now, View and Mongoose have a lot
Speaker 3: of similarities internally in terms of the problems that they
Speaker 3: try to solve. Again, one of the uh one of
Speaker 3: the core parts of Mongoose is is has changed tracking
Speaker 3: in the sense that you load a document from the database,
Speaker 3: you assigned some properties to the document, and then you
Speaker 3: type save. Mongoose tracks the changes that you made and
Speaker 3: only sends the changes that you made the database, as
Speaker 3: opposed to trying to write the whole document.
Speaker 2: So now where is I was going back and listening
Speaker 2: to simpots from past episodes like twenty twenty twenty twenty
Speaker 2: one on Views on View where we were talking about
Speaker 2: Mangos mongoose. So I know Dino's you know, has been
Speaker 2: around for a while a few more years since then,
Speaker 2: is uh this mongoose compatible with Dino?
Speaker 3: Yeah, I think we technically still have a helpful support
Speaker 3: for Dino, and we do. We have been testing on
Speaker 3: Dino for several years, so I think it's reasonably stable.
Speaker 3: But I haven't really used Dino very much, to be
Speaker 3: perfectly frank like, I am not sufficiently confident, and I
Speaker 3: haven't seen enough enough interest in using mortgage with Dino
Speaker 3: to than justifys saying like, hey, this is like an
Speaker 3: officially supported thing. I'm seeing more usage for BUN, so
Speaker 3: I'm kind of curious to tinker with how Moggy's works
Speaker 3: on the bond, But I haven't had time to work
Speaker 3: on that either.
Speaker 2: Now it was, but I'm I've you heard about bun
Speaker 2: and see a list? Is that more just a run
Speaker 2: time or is that something you would write apps in
Speaker 2: like you would Node?
Speaker 3: From what I gather you, yes, you would write and
Speaker 3: you would write applications and fun I've heard of some
Speaker 3: interesting app frameworks that are specific to BUN. I think
Speaker 3: there's Alicia JS something like that. I think that one
Speaker 3: down there. I think that one is very BUN specific,
Speaker 3: and I've heard very good reviews about it. I think
Speaker 3: one thing I liked when I reviewed Alicia Elisia. I'm
Speaker 3: going to sorry if I'm butchering the pronunciation. One thing
Speaker 3: I really liked about that Express does not support is
Speaker 3: Alisia has good support for server sent events, kind of
Speaker 3: right out of the box. So if you pass it in,
Speaker 3: it gives the other developer experience that I've always wanted
Speaker 3: for service sent events, which is you pass in a
Speaker 3: acink generator function and then whatever your acin generator function
Speaker 3: yields that that gets admitted as a server event, which
Speaker 3: is really cool. Love that I actually use that pattern
Speaker 3: in the Malgi studio back end as well. Yeah. One
Speaker 3: UI decision that we made probably a couple of months
Speaker 3: ago in Mugu Studio that has paid huge dividends is,
Speaker 3: like traditional database viewers, you frequently load query results in pages.
Speaker 3: So you would so if you execute a query, you
Speaker 3: get twenty results back you get or there's let's how
Speaker 3: you execute a query and there's forty results you typically
Speaker 3: get twenty results at a time as a page, but
Speaker 3: the query, but when you execute the query, you don't
Speaker 3: get to see the results one at a time. If
Speaker 3: you wear uh, the the gooey waits until it gets
Speaker 3: all twenty results and then displays the twenty. With Mogus Studio,
Speaker 3: we've actually made it so that we use server sent
Speaker 3: events to stream the results as they come at in
Speaker 3: so even though you load twenty at a time, you
Speaker 3: get kind of like, okay, the instant that this document
Speaker 3: is available, we stream it to the front end, and
Speaker 3: the front end gets it to you kind of see
Speaker 3: like more of a smooth loading effect. And then there's
Speaker 3: infinite scroll back then too, so of course you if
Speaker 3: you want to scroll and view more data, well you
Speaker 3: get kind of a smoother experience where you're running one
Speaker 3: documents one at a time as opposed to kind of
Speaker 3: like gang Chunks twenty twenty twenty. And it really is important,
Speaker 3: especially in cases where you have a very slow running query,
Speaker 3: like if you're filtering logs or something like that, where
Speaker 3: you expects, okay, I may get like one or two
Speaker 3: log results really quickly, but then it may take twenty
Speaker 3: seconds to get all the log results, so it's more
Speaker 3: it's important to kind of get some of the data
Speaker 3: first or get the results as they come in case
Speaker 3: with long running queries. Service centerventsive great for that. Ye
Speaker 3: have you guys been working with with the Dino or
Speaker 3: bun at all? I have it.
Speaker 2: Most of my back end, I generally focus on PHPU
Speaker 2: and label just because that's been you know, where I
Speaker 2: started on the server side. So no, I haven't had
Speaker 2: much opportunity to work with with Note or mon Ordino itself.
Speaker 2: Like I said, just Mango in the context of a
Speaker 2: large letter bill view application.
Speaker 1: Yeah, and I mostly do Ruby on rails on the
Speaker 1: back end, So.
Speaker 3: Yeah, I guess I'm in the minority as someone that
Speaker 3: does server side jobscript pretty much exclusively. And like all,
Speaker 3: I describe myself as like a back end heavy full
Speaker 3: stack de alter in SnSe that in my team, we
Speaker 3: typically focus more on the back end and build pieces
Speaker 3: en upfront ends. Our frontucts are not our shrunk suit,
Speaker 3: but we do.
Speaker 2: Sound like me. Yeah, when it comes to the JavaScript
Speaker 2: side of things, I'm really good at you know, if
Speaker 2: I'm handling data, you know, communicating with the back end
Speaker 2: and getting data, displaying and data and that kind of stuff.
Speaker 2: You know, one of the data management type of application
Speaker 2: A pretty good when it comes to the UI and
Speaker 2: making it really pretty and design and stuff not so much.
Speaker 3: Yeah, well, these days the AI does a pretty decent
Speaker 3: job of that. Oh ish. One thing I've seen is that,
Speaker 3: like you know, the AI tools are still not quite
Speaker 3: as good as people as like spurts in that space. Right,
Speaker 3: So you know, if I if I build something, just
Speaker 3: if I just have clawed one try to one shot something,
Speaker 3: it's not going to be as good as the tailwe
Speaker 3: guy built some spoke lay up for me, but it'll
Speaker 3: be it'll be probably like seventy percent is good and
Speaker 3: maybe that's good enough. Yeah, exactly.
Speaker 2: I've been trying to play around and find some different
Speaker 2: tools that would be good at at creating like a
Speaker 2: you know, some sort of UI template you know, that
Speaker 2: I could implement on the front end at least looks
Speaker 2: decent and better than what I would come with on
Speaker 2: my own.
Speaker 1: Cool. Well, is there anything else that we should dive
Speaker 1: into here?
Speaker 3: Well, there was one topic that we want to talk
Speaker 3: about I mentioned earlier, the data API at Cassandra Integration.
Speaker 3: Oh yeah, that's something that's interesting. Oh, so yeah, we're
Speaker 3: for probably the last year two we've been we've been
Speaker 3: working with what Data Stacks, which recently got acquired by
Speaker 3: IBM to build a plug in that. Let's mongoose talk
Speaker 3: to the stack of Data API, which is kind of
Speaker 3: like an HDT layer on top of the Patrick Cassandra.
Speaker 3: So one of the neat things you can do with
Speaker 3: mongous now is you can actually or you can actually
Speaker 3: like just find wright molecuse code dropping a couple of
Speaker 3: lines of figuration and habit talk to Patrick Cassandra with
Speaker 3: with some pasttrisks as opposed for features that are supported
Speaker 3: and whatnot. And then now the neat things you can
Speaker 3: do like Magus is populate, which is kind of like
Speaker 3: Malgus's application level level joins gosh. I use that to
Speaker 3: take data from Manga to be populates some data from
Speaker 3: Cassandra or vice versa. It's pretty cool thing, I think.
Speaker 2: So for the uninitiated, can you explain what Cassandra is
Speaker 2: because I didn't know myself until I went and.
Speaker 3: Looked Patrick Cassandra is. It's a no SQL database but
Speaker 3: quite different from malgady B in the sense that like
Speaker 3: it still stores data and what kind of looks like
Speaker 3: Rosen columns, but it is like what's called a y
Speaker 3: columns store. I think the big selling point for Cassandra
Speaker 3: is it is it's good for massive right throughput, like
Speaker 3: the classic. The big example of probably the biggest Cassandra
Speaker 3: deployment that I could think of off the top of my
Speaker 3: head is is Apple iCloud. So let's say every time
Speaker 3: that you take a photo on your iPhone, metadata associated
Speaker 3: with that photo, like who took it, when they took it,
Speaker 3: that gets dumped into a two hundred and fifty thousand
Speaker 3: last I checked, no Cassandra cluster, or at least the
Speaker 3: last time I read about this. Yeah, Apple iCloud is
Speaker 3: one big deployments discord messages for a long time. We're
Speaker 3: we're also in a Patrick Cassandra and pretty much like name,
Speaker 3: like a major tech company that's not Google, they probably
Speaker 3: have a Cassandra deployment. Like Cassandra is actually originally written
Speaker 3: by Facebook. The open source de debated. I think it
Speaker 3: was like originally written to ah as like the back
Speaker 3: end store for the timeline view, but.
Speaker 2: It sounds like it's more it's not like something to
Speaker 2: use for small laps. It's more of an enterprise, huge
Speaker 2: implementation type application, right.
Speaker 3: Yeah, exactly. Now, one of the things they're trying or
Speaker 3: that they're trying to do is like make the Sandra
Speaker 3: more accessible using that data API, and Mongoose is part
Speaker 3: of that as well. There's a lot of content out
Speaker 3: there on how to use monkeys. The munguse kind of
Speaker 3: like plugs neatly into into the the sex data API,
Speaker 3: which kind of exposes like a Mango like layer on
Speaker 3: top of Sandra.
Speaker 1: Yeah, I've done a little bit with the Cassandra and
Speaker 1: it's it's kind of an interesting set up with the
Speaker 1: column near focus and things like that.
Speaker 2: But so it's no SQL because it's not SQL. But
Speaker 2: it's different than mongo ters or.
Speaker 3: How in the sense that they have, like they have
Speaker 3: a language called CQL Cassandra Corry language, which is similar
Speaker 3: to SQ well but heavily simplified.
Speaker 1: And they strictly speaking don't have a rigid schema kind
Speaker 1: of like what Mango does. But yeah, their performance characteristics
Speaker 1: are different and they kind of focus in a different
Speaker 1: way of thinking about your data. So depending on what
Speaker 1: you're doing, you would pick Cassandra over mongo I'm not
Speaker 1: sure I'm the right person to explain when you would
Speaker 1: pick one over the other.
Speaker 3: But yeah, I think historically I'm not sure like how
Speaker 3: accurate this is right now, but historically them was like,
Speaker 3: if if you have for read heavy data or data
Speaker 3: where you're incrementing a counter where like it's crementing data
Speaker 3: in place, you would probably use manga to be And
Speaker 3: if you have something where you're just writing something as
Speaker 3: fast as you can, you would use at Sandra m
Speaker 3: I'm not sure how accurate that is right now, but
Speaker 3: that tends to be the way that I think about things,
Speaker 3: although recently I've also been using Cassandra more or data
Speaker 3: api more for vector search, because one of the things
Speaker 3: that I really I think Cassandra did really well recently
Speaker 3: is they have they've taken vector search and made it
Speaker 3: a part of the core Cassandra and now that's exposed
Speaker 3: throughout through data Api as well, Whereas with muggerity b
Speaker 3: it's still like h vector search is still like an
Speaker 3: Atlas only thing. Like you if you're running muggity B
Speaker 3: by itself locally, you don't get ex your search, which
Speaker 3: is not not a complete deal breaker in the sense
Speaker 3: that for the most part you're going to be running
Speaker 3: production deployments and outlets like even I don't run even
Speaker 3: I don't run my o mugity Be closers anymore, but
Speaker 3: it does kind of. It is a bit of a
Speaker 3: pain point in terms of local development.
Speaker 2: So basically you can unless you're like hosting it on
Speaker 2: Atlas or something like that, unless.
Speaker 3: Or or running manga to be locally via the Atlas
Speaker 3: cl I. However, like running it locally by the Atlas
Speaker 3: cl I also comes with caveats and restrictions that you
Speaker 3: don't have if you're you're running you're running one mangity
Speaker 3: be locally, there's there's caveats there.
Speaker 1: Cool, Well, I've got about ten minutes before I have
Speaker 1: to jump off. Or are there other things that you
Speaker 1: guys want to keep talking about or should we do picks?
Speaker 2: But just real quick, the one question I had was
Speaker 2: you admit now you mentioned at the beginning that you
Speaker 2: use view whenever you have to whenever you need, you know,
Speaker 2: job to script front end. So is that just in
Speaker 2: in the UH, the UI or where else do you
Speaker 2: use view at least with Mango.
Speaker 3: For front endy wise, either either your service side rendering
Speaker 3: or single page app Another thing that we use viewfore
Speaker 3: is email temple, but we'll send emails we are email
Speaker 3: templates are also in view.
Speaker 2: Oh okay, you just have to use some single file
Speaker 2: components that format your your email.
Speaker 3: Not single file components, and we typically use were typically
Speaker 3: used two file components in the sense that we have
Speaker 3: JavaScript in HTML, so our emails look more along the
Speaker 3: lines that there's like there's order confirmation dot JS and
Speaker 3: order confirmation dot HTML. And that defines a component that
Speaker 3: renders a that renders our order confirmation. So I can
Speaker 3: we write out we define our uh, we define the
Speaker 3: layout in an HTML file. Historically, we found that easier.
Speaker 3: I have considered switching to single file components in recent
Speaker 3: years because I think that as I thought that way,
Speaker 3: I could do a better job with single files. But
Speaker 3: we're still sticking the separate JS and htmail files for
Speaker 3: now and then just to find to find emails in
Speaker 3: each GM because we found the comput is really good
Speaker 3: at just beef work things like that, like basic loops
Speaker 3: computer properties. That makes email rendering much easier.
Speaker 1: Mm hm cool, Well, I'm gonna I'm gonna push us
Speaker 1: into picks, so, uh, Steve, do you want to start
Speaker 1: us off with picks?
Speaker 2: Certainly, nothing really pickwise other than the high point of
Speaker 2: all of repros. That's the dad jokes of the week,
Speaker 2: So I'll dive right into those real quick. So when
Speaker 2: I was growing up, one of my favorite memories of
Speaker 2: my childhood was I used to build sand castles, you know,
Speaker 2: with my grandmother, and then my mom took the urn
Speaker 2: away from me, right, I sort of like the joke
Speaker 2: about where I was at washing cars with my son
Speaker 2: and he's like, Dad, can we just use a sponge?
Speaker 2: But and then people say, when people say you look
Speaker 2: so familiar, do I know you? I find that if
Speaker 2: I say were we in prison together? Really ends the
Speaker 2: conversation every time. And then finally I was talking to
Speaker 2: my insurance age and I said, I hit an animal
Speaker 2: and my car is total on my copboard. He goes, yeah,
Speaker 2: what'd you hit? And I said a fish? And that
Speaker 2: joke sort of comes with the car in the water.
Speaker 2: Maybe it's a little more of a visual joke, but anyway,
Speaker 2: those are the dad jokes of the week.
Speaker 1: All right, I'm going to jump in here with some
Speaker 1: pisure really quickly. So I'm going to pick a game
Speaker 1: I've been playing a lot lately with my buddies. I
Speaker 1: know I've picked it before, but I'm just gonna pick
Speaker 1: it again because I didn't have time to look one up.
Speaker 1: It's called the Gang. Play it in like fifteen to
Speaker 1: twenty minutes. It's essentially group poker, like cooperative poker. And
Speaker 1: so what you do is you have chips that are
Speaker 1: numbered from one to however many players are playing it
Speaker 1: has up to six, and then you deal everybody out
Speaker 1: their whole cards or their pocket cards, you know, the
Speaker 1: two cards you start with in Texas. Hold them, and
Speaker 1: then everybody grabs a chip and you try and get
Speaker 1: it in order of who has the best hand down
Speaker 1: to who has the worst hand, and then you flip
Speaker 1: the flop and you do it again right, and then
Speaker 1: you flip the turn, and then you you know, do
Speaker 1: the same thing, and they flip the river, and after
Speaker 1: the river on the red chips. Then whoever has the
Speaker 1: number one chip flips theirs over first. They should have
Speaker 1: the worst hand. Whoever has the number two should have
Speaker 1: a better hand, three, four, five, and all the way
Speaker 1: up to six, or if you're only playing with three people,
Speaker 1: you know, all the way up to three. I was
Speaker 1: playing it with my kids the other day and yeah.
Speaker 1: So the only other rule is is you can talk
Speaker 1: about everybody else's hand, but you can't talk about your own.
Speaker 1: So at one point, for example, we had flipped the
Speaker 1: turn card, and so which is the fourth card in texas?
Speaker 1: Hold him? And it was a ten, and so my
Speaker 1: son grabbed the number three chip because of whatever the
Speaker 1: three of us playing, because he in his whole cards
Speaker 1: he had a ten, and so he had a pair
Speaker 1: of tens. And so I looked at him and I said,
Speaker 1: if you matched, just now, you have a pair of tens.
Speaker 1: And then I grabbed the three chip and put it
Speaker 1: in front of me because I had a pair of
Speaker 1: jacks from the flop, and so that told him. So
Speaker 1: I didn't talk about my hand, but I indicated him
Speaker 1: I know what you have and I have a better hand.
Speaker 1: And so anyway, so that's kind of the way you
Speaker 1: do it. If there are more pople you tend to
Speaker 1: talk through a lot more things. With my buddies, we
Speaker 1: also like to call out you know, for example, if
Speaker 1: you have two clubs, then you have a flush, right
Speaker 1: because there are three clubs cards in the you know,
Speaker 1: in the in the shared cards. Or if you have
Speaker 1: a two and then six, then you have a you
Speaker 1: have a straight right, which is a run of five
Speaker 1: cards in number order. And so anyway, so it's a
Speaker 1: lot of fun and like I said, we you know,
Speaker 1: we just you know, you can play through pretty quick.
Speaker 1: You're trying to get three correct before you get three incorrect,
Speaker 1: and that's how you win the game. And yeah, like
Speaker 1: this it takes like twenty minutes. So I'm going to
Speaker 1: pick that for the game. I've also wanted to really quickly.
Speaker 1: I was texting. I've started this thing where I start
Speaker 1: texting people that I haven't talked to in a while.
Speaker 1: And so one person that I texted, let me find
Speaker 1: the text because I told him I was going to
Speaker 1: share some stuff. But I was texting with can Kent
Speaker 1: Kent Dodds, and I might just have to search it here.
Speaker 2: Wow, talk about name dropping.
Speaker 1: Well he lives out here and so periodically, well you know,
Speaker 1: hang out or whatever. But yeah, so he said that
Speaker 1: he's been doing a couple of things, so I'm just
Speaker 1: going to shout out his websites. He has epic ai
Speaker 1: dot Pro, so he's been teaching people to do AI stuff.
Speaker 1: He's also got epic web dot dev, which is kind
Speaker 1: of his full stack preferred stack, and so I don't
Speaker 1: know if he's still doing remix, but you know, that
Speaker 1: used to be a big part of it. And then
Speaker 1: he had a whole bunch of other stuff that hed
Speaker 1: pull in. And then he also has epic React dot dev.
Speaker 1: So if you're looking to learn stuff about React, JavaScript
Speaker 1: or AI, then he's got He's got some resources out
Speaker 1: there that you go check out. I find that his stuff
Speaker 1: is reasonably easy to follow along with, and so I
Speaker 1: don't have any problem shouting that out. So I'm doing that,
Speaker 1: and yeah, I'm also just going to shout out the
Speaker 1: idea of, you know, find for people to reach out
Speaker 1: to every day. I mean, I do it with family members,
Speaker 1: I do it with people in the tech community. It's
Speaker 1: kind of fun because sometimes I haven't heard from him
Speaker 1: in a couple of years, like I had. I don't
Speaker 1: think I've really talked to Kent in a couple of years, right,
Speaker 1: and so it was like, oh, hey, and so we're
Speaker 1: catching up on kids and things like that. Anyway, So yeah,
Speaker 1: that's kind of what I've been doing. And I picked
Speaker 1: that up from Jordan Harbinger. I was listening to him
Speaker 1: do an interview with somebody and he said that he
Speaker 1: does that, and I was like, there are a lot
Speaker 1: of people I want to stay connected to that I don't,
Speaker 1: And so anyway, I'm going to shout that out as well.
Speaker 3: What are you think I reached out to Jordan? I
Speaker 3: haven't spoken him in a few years.
Speaker 1: Yeah, I haven't either. Last time I talked to him,
Speaker 1: I had to drop some money.
Speaker 2: So we should get Can on the podcast again.
Speaker 1: We should. I'll ping him and see if he wants
Speaker 1: to come on. All right, Val, what are your picks?
Speaker 3: Yeah, check out Magus Studio, Mangu studio dot app Alicia J.
Speaker 3: S Alsos dot com worth worth checking out. Actually it's
Speaker 3: in the public chat already. But is the L y
Speaker 3: s I a J S dot Okay? Yeah, yeah, that's yeah.
Speaker 3: I told you I was going to butcher the pronunciation,
Speaker 3: so sorry in advance. I tend to like not listen
Speaker 3: to video. I tend to read things so frequently I
Speaker 3: read things and I just don't know how sorry about that.
Speaker 3: So yeah, that that one. I haven't actually played with
Speaker 3: it yet, but it's got some interesting patterns and I
Speaker 3: think I'll looking into thinking about especially related to servers
Speaker 3: events and then yeah, recently, I've been using to do
Speaker 3: list a lot more. I've kind of gone back and
Speaker 3: forth on like DIF to do list tools, and I
Speaker 3: just keep coming back to this one or specifically for
Speaker 3: like personal tasks. So it's it's a great replacement for
Speaker 3: just for like having a to do dot t x
Speaker 3: T or for having sticky notes or something. So I
Speaker 3: like having kind of like three, like a list of
Speaker 3: three or four tasks, like these are the important things
Speaker 3: I need to get done today. And it can be
Speaker 3: work related, it can be just like if I have
Speaker 3: Valentine's Day gift for my wife, which is still on
Speaker 3: my on my list right now, so you got reminding me.
Speaker 2: That one read.
Speaker 3: Yeah, just having like a list of things that that
Speaker 3: I want to be front center, like these are the
Speaker 3: things I need to get done. To do US is
Speaker 3: a great way for that because they got, oh they
Speaker 3: got a great web app, they got a great mobile app,
Speaker 3: and they have a nice, little simple user interface that
Speaker 3: encourages you to only have a handful of things on
Speaker 3: your list. So it's never going to replace like a
Speaker 3: linear or Gira or something for managing a long backlog task,
Speaker 3: but it is a good way to just kind of
Speaker 3: have like a quick sticky notes thing for yourself to
Speaker 3: keep track of important things.
Speaker 2: So are you still doing the mastering JS at all?
Speaker 2: I don't think know if I've seen.
Speaker 3: Lee in a while, I have been not working on
Speaker 3: it as much. Actually, I've been kind of like letting that,
Speaker 3: laying that run, because the idea like mastering JS was
Speaker 3: kind of more about like get it like a tech
Speaker 3: tutorial se O, which is a game that has become
Speaker 3: very played out in the post AI era. People don't
Speaker 3: go to Google for code questions as much anymore. To
Speaker 3: traffic for that website has fallen substantially since the yeah
Speaker 3: you saw the if you saw the tailwind stuff, it's
Speaker 3: not that fairly similar in the sunset. Yeah, Like with
Speaker 3: the traffic to mangus jas dot com and mastering js
Speaker 3: dot io pretty much peaked exactly in August September twenty
Speaker 3: twenty two, and then it's been at the client sets,
Speaker 3: which hasn't affected us that much right now, but we
Speaker 3: don't really rely on the ad revenue right there, but
Speaker 3: it's definitely been definitely been something that we've noticed in.
Speaker 2: The thought about Yeah, interesting that Jeffrey Ray is the
Speaker 2: guy that does Leerraic cass He put out a video
Speaker 2: here in the past week. We're so talking about that
Speaker 2: and the impact that AI has had on his site
Speaker 2: in their courses and stuff like that too. It's an
Speaker 2: interesting listen.
Speaker 3: Yeah, the the impact of AI on our industry is
Speaker 3: it's it's gonna be. It's still happening. It's it's huge
Speaker 3: so far, and it's gonna keep getting bigger, so we
Speaker 3: I honestly, it's somewhat exciting. It's an exciting but somewhat
Speaker 3: scary time to be in software engineering because, Aslee, no
Speaker 3: idea what our industry is going to look like in
Speaker 3: five years. I agree with DH on that, on that assessment.
Speaker 2: Yeah, someone who's job hunting right now, I can vouch
Speaker 2: for that. It's pretty brutal out there.
Speaker 1: Yeah, all right, I've got to jump off. I've got
Speaker 1: a work meeting. But thanks for coming, Val.
Speaker 3: Yeah, thank you for having me, Chuck, It's always great
Speaker 3: to see you.
Speaker 1: Yeah, you too, And yeah, until next time, folks. Max
Speaker 1: out