Speaker 1: Hey, folks, Welcome back to another JavaScript jabber. This week
Speaker 1: on our panel, we have Dan Shapeer.
Speaker 2: Hello, from what we in Tel Aviv like to call
Speaker 2: it winter.
Speaker 1: Well, I wish our winters were that warm. I'm Charles
Speaker 1: Maxwood from top Endevs, where I think you got below
Speaker 1: freezing last night. That zero if you're not in the
Speaker 1: US and use something other than fahrenheit, and that's like
Speaker 1: thirty two degrees fahrenheit, So got real cold last night.
Speaker 1: This week, we're following up on the nine Node Pillars
Speaker 1: episode that came out a few weeks ago or a
Speaker 1: month ago, so we've got some familiar faces, but we'll
Speaker 1: go ahead and let them introduce themselves again. I'm just
Speaker 1: going to start at the top of my screen and
Speaker 1: we'll just kind of work our way down. We have
Speaker 1: Michael Dawson. Michael, do you want to introduce yourself?
Speaker 2: Hi?
Speaker 3: Michael Dawson on the NODS lead for Rahat and at
Speaker 3: GM as well as active in the project from the
Speaker 3: Technic Steering Committee and live definitely where it is getting
Speaker 3: below zero at nineteen.
Speaker 1: Right, practically, neighbors. We also have Matteo Colina.
Speaker 4: Hi, everyone, I'm mate Coolina Platmatic co founder and CEO
Speaker 4: ps enter on the mat jest I think, a steering committee,
Speaker 4: a board member of the Opinion Jazz Foundation. Also of
Speaker 4: many modules. You are probably using my software, even if
Speaker 4: you don't, even if you want or not.
Speaker 5: Probably my tagline awesome.
Speaker 1: We also have James Snell.
Speaker 6: You know, uh yeah, James del Con from central California
Speaker 6: where winter here means just slightly less unshine than I'm
Speaker 6: at Claude Flair. I work on their workers run time.
Speaker 6: I'm on the Note technical Steering Committee. I've been contributing
Speaker 6: to Note for most ten years. We have in March
Speaker 6: in just a few months, I'll have been on the
Speaker 6: technical Steering committee for Note for ten years old decades,
Speaker 6: so which is which is crazy? Yeah, that's.
Speaker 1: Awesome. And finally we have Natalia Vendito.
Speaker 7: Yeah, thank you for having me.
Speaker 8: I am the lead for developer tools and Experiences for
Speaker 8: the script on usure and yeah, also participation of the
Speaker 8: Open Jes foundations.
Speaker 7: We see, that's me.
Speaker 1: So yeah. So last time you talked about the nine
Speaker 1: node pillars, I think it's worth maybe a five ten
Speaker 1: minute review something like that, just trying to get people
Speaker 1: back into it. Obviously, folks can go back and listen
Speaker 1: to the other episode if they want the in depth discussion,
Speaker 1: but then we should.
Speaker 2: It was an excellent They definitely should. It was an
Speaker 2: excellent conversation, it's an excellent article, and it's an it
Speaker 2: was an excellent conversation in my opinion, unbiased opinion.
Speaker 1: Well, my point is is then we can get on
Speaker 1: with the other you know, four or five pillars, So
Speaker 1: really quickly, I'm just gonna pull them out of the article,
Speaker 1: and then if whoever wants you can kind of jump
Speaker 1: in and just kind of summarize what was discussed. The
Speaker 1: first one is do not block the event loop.
Speaker 6: Yeah, this one's pretty straightforward.
Speaker 2: You know.
Speaker 6: It's like, you know, you got to keep in mind
Speaker 6: that anytime you're running some bit of jobascripts, you have
Speaker 6: some function, nothing else is going to happen on that
Speaker 6: event loop. So you need to make sure you're dividing
Speaker 6: your work into two very small chunks. Allow the event loop.
Speaker 6: It turns you can pick up new requests, you can
Speaker 6: process io that that kind of thing. So pay attention
Speaker 6: to you know, that event loop delay, event loop utilization.
Speaker 6: There's a couple of metrics there. You really want to
Speaker 6: watch closely and optimize your applications around that.
Speaker 2: Yeah, and also offload if you can lengths casts to
Speaker 2: a worker a total post support.
Speaker 1: Yeah, and I'm assuming you talked about strategies on how
Speaker 1: to do that and what your coach should look like
Speaker 1: in the other episode.
Speaker 3: So yep, yep.
Speaker 1: The next one is monitor node specific metrics and act
Speaker 1: on them.
Speaker 5: Let me take this.
Speaker 4: Most of the things that people do when the plying
Speaker 4: no JS is they monitor no JS like it's in
Speaker 4: a completely like it's a black box. And this is
Speaker 4: a massive it's a massive pain because you because in
Speaker 4: most cases no JS has its own quirks and peculiarities,
Speaker 4: and monitoring a black box, you are essentially making it
Speaker 4: a service. Biggest one being memory. JS will use as
Speaker 4: much memory as you make it available to it. And
Speaker 4: if you start killing it when it reaches whatever arbitrary threshold,
Speaker 4: you know you're killing the process yourself. And and then
Speaker 4: you're starting it and complaining that your process is crashing
Speaker 4: all the time you're killing it, of course is crashing
Speaker 4: all the time. Okay, it's literally like this thing alone
Speaker 4: is probably don't know worth a few hours of fright time,
Speaker 4: super high end colsantacy. So this is for free, so
Speaker 4: you know to take it, take it the way you want.
Speaker 4: But this is essentially, you know, very easy fix. But
Speaker 4: most people don't Most people monitor assess micos if you
Speaker 4: use it, but don't look into what's happening inside the process.
Speaker 5: And this is you know, makes all the difference.
Speaker 6: One of the key metrics there that was added relatively
Speaker 6: recently is the event look utilization. It's going to say
Speaker 6: you a whole lot more information than monitoring a CPO.
Speaker 1: Yeah, awesome. The next one is use node LTS, which
Speaker 1: is long term support versions in production.
Speaker 3: I think that one is like, you know, as a project,
Speaker 3: we support the long term support streams and the recommendations
Speaker 3: really stick with those because in terms of security effects
Speaker 3: and stuff like that, that's where you're going to get
Speaker 3: those and most people don't want to update when those
Speaker 3: come out.
Speaker 2: And these are the even numbered versions, right, that's.
Speaker 3: Right, and they come out every October and are supported
Speaker 3: for thirty months.
Speaker 1: They usually say LTS. It's like it's the version number
Speaker 1: that says LTS. So if you have a question, just
Speaker 1: look for that and you'll know. I think we all
Speaker 1: kind of stared at each other on that one, Like
Speaker 1: it was pretty clear that that's a good move. The
Speaker 1: fourth one is automate testing, code re view and conformance
Speaker 1: as much as possible.
Speaker 3: Yeah, that one I'll jump in. We talked about last time.
Speaker 3: I think like no just is known for being able
Speaker 3: to let you move really fast and be productive, but
Speaker 3: you need really good testing to be able to move
Speaker 3: quickly to make sure you're not going to break things.
Speaker 3: And so that's where we last time. We talked about
Speaker 3: like how that how it is really your enabler to
Speaker 3: take advantage of the sort of speed and agility that
Speaker 3: node gives.
Speaker 2: We also spoke about the fact that people still use
Speaker 2: old testing frameworks which are showing their age, and that
Speaker 2: Node now comes with its own built into framework that
Speaker 2: you can really easily leverage out of the box.
Speaker 1: Good deal. And then it sounded like you got part
Speaker 1: way into but didn't completely discuss avoid dependency creep.
Speaker 2: Yes, we spoke at length about how NPM it's kind
Speaker 2: of like this black hole which sucks the entire universe
Speaker 2: into it. So you add one dependency which brings on
Speaker 2: another couple for the ride, which bring even more and
Speaker 2: more and more. And we talked about the fact that
Speaker 2: you need to really be how would I say it,
Speaker 2: cognizant of what you're bringing in intentional I think was
Speaker 2: the term that we use. Think about what you're bringing
Speaker 2: in and why you actually need it, and if there
Speaker 2: are lighterweight alternatives, and beware utilizing multiple versions of the
Speaker 2: same library. Anything else we mentioned that I'm missing, Yeah, I.
Speaker 3: Think that one of the aspects was like within an organization,
Speaker 3: the great the good thing about NPM and all the
Speaker 3: choices there is there's lots of different choices, but like
Speaker 3: in an organization, it would make a lot of sense
Speaker 3: to choose a more standardized set of packages as opposed
Speaker 3: to having five copies of something which does the same
Speaker 3: thing but are actually slightly different. Because when it comes
Speaker 3: to helping each other or to debug issues or to
Speaker 3: be able to support them, that can be an advantage.
Speaker 3: Of course, you know, there's always cases where you want
Speaker 3: to use something special to your particular effort, but like
Speaker 3: that's probably the twenty percent case versus the eighty percent.
Speaker 2: By the way, with regard to that one thing that
Speaker 2: I'm thought of and I don't think I mentioned the
Speaker 2: last time we spoke about this, is the fact that
Speaker 2: I know some organizations that intentionally take call it micro
Speaker 2: front ends micro services type approach of trying to create
Speaker 2: as much segregation as possible between various teams and reduce
Speaker 2: teams dependencies or dependency on each other. And that means
Speaker 2: that for example, one team might choose to use one
Speaker 2: package or library and another team should be free to
Speaker 2: choose something else, or that they don't need to move
Speaker 2: at the same rate with regard to version ing and
Speaker 2: stuff like that. Now, obviously they if they go the
Speaker 2: way or the whole way with microservices, then they're probably
Speaker 2: also running separate node instances, which might reduce the impact,
Speaker 2: but they might be running within the same note instance,
Speaker 2: and then they're kind of working in contradiction to this recommendation.
Speaker 3: I think, like if you look at it, like maybe
Speaker 3: that plays into not using like not forcing people to
Speaker 3: be using the same version. But I still think even
Speaker 3: in that case, there's value to say, like let's all
Speaker 3: choose the same loger, right, Like we don't need to
Speaker 3: use ten different bloggers. So for example, if somebody moves
Speaker 3: from one team to the other, they they already know
Speaker 3: the log or in the patterns and so forth they're
Speaker 3: used and breaking it up into micro services like that's
Speaker 3: sort of a different kind of dependency in my mind.
Speaker 1: Anyway, Yeah, I agree. I've worked on a number of
Speaker 1: projects where we you know, we try to segregate things
Speaker 1: out this way, and what I found is that sometimes
Speaker 1: there are good reasons for deviating from what the other
Speaker 1: teams are doing, and sometimes there really aren't. And so
Speaker 1: a lot of this, you know, they try and segregate
Speaker 1: it so the teams don't have to spend as much time,
Speaker 1: you know, coming together and collaborating. But this is more
Speaker 1: of an organizational issue, I think, than than a code issue,
Speaker 1: in the sense that you should still be talking and
Speaker 1: you can still leverage the expertise of the other team
Speaker 1: where appropriate and say, all right, we've got to solve
Speaker 1: this problem. We know you have this same problem. What
Speaker 1: are you using And then you can have the discussion
Speaker 1: about what and where and why. And then when we
Speaker 1: look at it from our problem perspective, right, because we're
Speaker 1: working on a different part of the app, then we
Speaker 1: may say that all makes sense, and we tried to
Speaker 1: put it in, but it turned out these concerns lead
Speaker 1: us to a different solution. But then you have a
Speaker 1: good reason for saying this is why we're doing it
Speaker 1: different as opposed to the other thing. But it also
Speaker 1: then makes people more mobile between the teams. It makes
Speaker 1: it easier to talk about some of the similar issues.
Speaker 1: And so I think there's some nuance here, but I
Speaker 1: like the direction of saying, hey, at least consider what
Speaker 1: everybody else is doing in your organization.
Speaker 4: And part of my part of the concerns here is
Speaker 4: you really want to to even say okay. So we
Speaker 4: have created a way to a little module to call
Speaker 4: this micro service okay that is consumed by everybody okay,
Speaker 4: and I want to take that code and publish it
Speaker 4: on my internal registry because otherwise each other team is
Speaker 4: going to redew it, and each other team is going
Speaker 4: to use a different HDP library for calling it okay,
Speaker 4: which is bananas. I've seen this happening over and over again. Okay,
Speaker 4: literally time wasted due to writing API clients. But now
Speaker 4: we have a point there for top creating API clients.
Speaker 4: But this is essentially this is part of the problem.
Speaker 4: This is one of the problems. This happens to all
Speaker 4: the things okay.
Speaker 5: It is I need a library to validate that.
Speaker 4: My custom field is correct, right, and then I need
Speaker 4: this custom data. Well, let's put it somewhere so that
Speaker 4: I don't need to implement it all every every single time.
Speaker 6: So yeah, it just comes out of being intentional. You
Speaker 6: need to be more intentional than your opinion. Like engineers
Speaker 6: are going to have opinions. You know, I don't agree
Speaker 6: with the displiment right into the library. Does it a
Speaker 6: different way, And it's like in an organization, that's just
Speaker 6: not our work. You can get so far with it.
Speaker 6: Let's just cause more headaches and overhead. So do it once,
Speaker 6: publish it for everyone to use. And you know what
Speaker 6: if you don't agree with that one hundred percent, so
Speaker 6: what use it anyway?
Speaker 1: M Yeah, enterprise I agree, go ahead, Natalia sorry, yeah.
Speaker 7: Yeah, in enterprise development, I think many.
Speaker 8: People forget there is this intermediately year like everybody can
Speaker 8: consume from upstream.
Speaker 7: Whatever module they want.
Speaker 8: But again, like Matteo and James uh stay that, you
Speaker 8: need to be conscious of what you're building yourself and
Speaker 8: make it available to others. In the end, you have
Speaker 8: a smaller ecosystem with that within your company, your organization
Speaker 8: that allows you to publish to any private registry and
Speaker 8: also function in the same way as open source by
Speaker 8: within the boundaries of your organization.
Speaker 9: And by the way, this is.
Speaker 8: Definitely an organizational convenience, not so much at a metal one.
Speaker 8: I think in the front end, definitely try to keep
Speaker 8: dependencies that you're probably shipping over the wire minimum. But
Speaker 8: in the back end, what you want to do is
Speaker 8: to make sure that you have a lower maintenance requirement.
Speaker 7: Than when you have a lot of modules to maintain.
Speaker 2: One thing that I encountered with organizations thinking about reusing
Speaker 2: their own components within the organization. So sometimes they're very
Speaker 2: explicit about it. So for example, if an organization in
Speaker 2: the context of front and development, an organization decides they're
Speaker 2: going to have a design system and the implement some
Speaker 2: sort of a front end library that's pretty typical but working,
Speaker 2: and let's say in a certain project, and then coming
Speaker 2: to a conclude and hey, this bit of code that
Speaker 2: I wrote seems to be something that will be generally
Speaker 2: useful across the entire organizations. People have that a harm moment,
Speaker 2: but are sometimes hesitant to act on it because you're
Speaker 2: assuming a lot more responsibility than you originally had. Like
Speaker 2: if you're just writing something for your own use within
Speaker 2: your own team, that's one thing, but committing to support
Speaker 2: every use case within the larger organization. That's a different
Speaker 2: type level of commitment altogether, and making that jump can
Speaker 2: be you know significant.
Speaker 9: Yeah, that's true.
Speaker 7: I have sorry, go ahead, go ahead, Michael, I said.
Speaker 3: That seems to be the thing in life. The more
Speaker 3: you do, the more you pick up in terms of
Speaker 3: responsibility of keeping things going. So I can totally see
Speaker 3: people worrying about that.
Speaker 4: Now I have an absolute counter argument to okay, and
Speaker 4: I want to flag out this functional and why you
Speaker 4: need to be intentional when creating this kind of software,
Speaker 4: when when thinking about dependencies and software usability within your
Speaker 4: organization and enterprise and also our enterprise about absolutely sabotage
Speaker 4: themselves while doing so. Okay, so imagine that each team
Speaker 4: needs to, you know, implement a piece of functionality. Okay,
Speaker 4: Now one of the teams that they discuss, one of
Speaker 4: the teams is the first one, and they created their
Speaker 4: own little module to do this, and this is well
Speaker 4: it it is. I'm publishing it on my NPM internal
Speaker 4: MPM rights. Great, everybody is happy, the management is very happy.
Speaker 4: We saved a maunch of money, so we need to
Speaker 4: can reuse all these things.
Speaker 5: Fantastic okay.
Speaker 4: Now, however, a moment after that's happened, the team that
Speaker 4: created that module completely drops the ball on it because nope,
Speaker 4: it's not part of my OKR anymore. The quarter has changed,
Speaker 4: so I'm not maintaining this anymore. And this is the
Speaker 4: typical thing that happens with okay, are okay? If what
Speaker 4: you're doing is not part of of your okay of
Speaker 4: of your does not help you achieve your key results,
Speaker 4: you are absolute that thing it needs to be dropped, okay,
Speaker 4: even though it's important and you know you're saving the
Speaker 4: compliant of money by avoiding duplications. So, in reality, a
Speaker 4: lot of teams in some enterprise works a little bit
Speaker 4: like silos.
Speaker 2: And they are a little bit.
Speaker 4: Yeah I have Yeah, I think Natali has a few
Speaker 4: stories on on that, so I don't know it's.
Speaker 8: But yeah, after a decad as an enterprise developer, I
Speaker 8: have many stories. Yes, there are silos, and I do agree, mate,
Speaker 8: But typically enterprise projects do not work under KPIs. The
Speaker 8: KPI is delivering your project's a little bit different than product.
Speaker 9: And another thing to your.
Speaker 8: Favor is that if you are building something that you
Speaker 8: publish to a private registry and you move to another project,
Speaker 8: which is usually the case of developers in the context
Speaker 8: of enterprise.
Speaker 9: You are rotating, you're going to a different project.
Speaker 8: You can reuse it, right, you have it, you have
Speaker 8: it available to your new project, whereas if it's part
Speaker 8: of a private code base, you don't have access to
Speaker 8: it anymore.
Speaker 6: Right, And I think that there's I'm gonna sorry, sorry
Speaker 6: for the dogs here, but only another aspect of this
Speaker 6: that's completely overlooked is a lot of times these internal
Speaker 6: teams will look at, hey, this other team created this,
Speaker 6: this package that I want to use, it's their responsibility
Speaker 6: to maintain it so I can get the benefit from it.
Speaker 6: That's internally the wrong calculus. It's if if if I'm
Speaker 6: up to use it in my project, I'm also picking
Speaker 6: up the burden to help maintain it.
Speaker 1: Uh.
Speaker 6: So you know, we can't have this idea that it's like, oh,
Speaker 6: that other team's responsible for it. No, no, no, all
Speaker 6: the same company, all the same team is equally my
Speaker 6: responsibility to anyone else.
Speaker 2: Let me be plunned if your assumption is that if
Speaker 2: you run into a problem because your needs change and
Speaker 2: the current and the package doesn't properly or adequately support it,
Speaker 2: and you're dependent on somebody from some other team who,
Speaker 2: as we said, may have different OKRs, different priorities, you're
Speaker 2: literally screwed. I mean, you have to take the attitude
Speaker 2: and the approach that if you're using it, you're assuming
Speaker 2: responsibility for it.
Speaker 3: That can almost still be totally extended to every module
Speaker 3: you use from MPM, because in that case, the people
Speaker 3: who who may be maintaining it are even further away
Speaker 3: from you and even have less reason to necessarily prioritize
Speaker 3: your your requirements.
Speaker 6: And I a hundred percent agree with that. I'm and
Speaker 6: I've said before many times. Where you know, especially companies,
Speaker 6: if you are making use of open source, then you
Speaker 6: as a company have an obligation helped support that open
Speaker 6: source that that you're using. That includes contributing back bug fixes,
Speaker 6: changes or whatever, and working with those maintainers. Don't put
Speaker 6: that burden on them, especially if you're not paying them.
Speaker 2: By the way, an interesting aspect that I've seen is
Speaker 2: that at least for some organization, when they decided to
Speaker 2: share some resource across the entire organization, it was actually
Speaker 2: easier from the organizational perspective to turn it into an
Speaker 2: actual open source project. Then to try to maintain it
Speaker 2: as an internally shared resource, because once it was declared
Speaker 2: an actual open source project, it was actually allocated resources
Speaker 2: versus when it was just an internal thing that's shared,
Speaker 2: you know, ownership was met.
Speaker 1: Yeah. One thing that I wanted to piggyback off of
Speaker 1: what Matteo was talking about a little bit earlier is that,
Speaker 1: and this is coming from when I was working on
Speaker 1: integrations and it was mostly third party integrations within an
Speaker 1: application that I was helping maintain. But also, you know,
Speaker 1: between micro services, is that if you can structure your
Speaker 1: because he was saying, you know, if you're writing the
Speaker 1: micro service, you ought to be writing the library that
Speaker 1: consumes it and giving everybody a standard way of accessing it.
Speaker 1: And for me, if you can structure all of those
Speaker 1: the same way and make sure that they all kind
Speaker 1: of look and feel and are built in the same manner, again,
Speaker 1: it makes it easier for people across the organization to
Speaker 1: be able to come in and do that maintenance for
Speaker 1: you so that they can you know, you can move ahead.
Speaker 1: So then it's hey, this micro service has this feature
Speaker 1: that they built in, but they have an updated the
Speaker 1: library for it, or maybe I need to make pull
Speaker 1: the data in, but I need to do something a
Speaker 1: little bit different with it before I consume it in
Speaker 1: my service. You know, if it's all structured in a
Speaker 1: similar manner, then I know where to go to go
Speaker 1: ahead and add that in and then everybody else benefits
Speaker 1: from it and I don't have to go in and
Speaker 1: reverse engineer this driver or that driver, or this integration
Speaker 1: library and that integration library.
Speaker 2: I do want to I do want to. Sorry, I
Speaker 2: do want to push us along a little bit because
Speaker 2: we are We're never going to finish the pillars.
Speaker 5: Otherwise I want I do want them today.
Speaker 2: Yeah, I do want to touch on two things that
Speaker 2: were mentioned in the article in this context, at least briefly.
Speaker 2: One is that no d APIs versus Web Standard APIs,
Speaker 2: and the other you also mentioned Mono repost. So can
Speaker 2: you talk about Can someone talk about the no JS
Speaker 2: standard Native standard APIs versus the Web Standard APIs.
Speaker 6: Yeah, I can definitely talk about that. You know, we
Speaker 6: have a number of places in node now, you know,
Speaker 6: the old r L parts versus new r L, node
Speaker 6: streams versus web streams, old node crypto versus web crypto.
Speaker 6: We have a lot of these cases where we have
Speaker 6: you know, duplicate or overlapping APIs. Let me talk you
Speaker 6: know you. R L is the very first one that
Speaker 6: I introduced, and there was a huge controversy even within
Speaker 6: the project. I was actually yelled at at a conference
Speaker 6: by another node contributor, like actually yelled at for suggesting
Speaker 6: that we add this because r L parts is there
Speaker 6: and and it's fast. Uh. And you know when we
Speaker 6: added the new r L pars er, the w g
Speaker 6: r O parser, when it was slower, but it was
Speaker 6: standard and folks, we use libraries for in node in
Speaker 6: browsers and then you know, picked it up and that
Speaker 6: you know, and something. You can use this thing everywhere.
Speaker 6: It's it's much more portant. Now, it's faster than anything else. Well,
Speaker 6: we're gonna see this pattern continue. And whenever you are
Speaker 6: whenever you're selecting which API, do us say node streams
Speaker 6: versus webstreams. Be very intentional. Don't just make it an
Speaker 6: accidental choice. Be very intentional on how you adopt these
Speaker 6: node streams are going to be way more performant than webstreams,
Speaker 6: but webstreams are way more portable. So you need to
Speaker 6: balance which goals you're looking for. And make sure you're
Speaker 6: selecting your dependencies accordingly. The more you have to translate
Speaker 6: between them, I say, if you're using both note streams
Speaker 6: and webstreams, the more overhead and easier it's going to
Speaker 6: be to get it wrong. So you need to be
Speaker 6: very intentional about your strategy in which API is you're picking.
Speaker 6: But something zu pers just don't use it anymore, use new.
Speaker 4: Your something important is. No JS in general has added
Speaker 4: a lot of APIs in the last decade, okay, and
Speaker 4: the most people still development JS like it's twenty fourteen,
Speaker 4: so please stopkin take a look at work there. Okay,
Speaker 4: like literally, oh, we have fetch now, I was I
Speaker 4: was checking recently and we and you know a few
Speaker 4: of the top downloaded modules on MPM are high level
Speaker 4: HDP clients, and we had fetch for a while in
Speaker 4: Node okay, and you know, and.
Speaker 6: Even simple u u I D, the uu i D module,
Speaker 6: a lot of folks, you you know, pull it off
Speaker 6: with NPM to just generate a random u i D. Great,
Speaker 6: it's a great module. But compared to the API that's
Speaker 6: built into node and browsers, we have Web standard API,
Speaker 6: which is random u I D until on the crypto obbit.
Speaker 6: It's way faster, way simpler, and it's just the thing
Speaker 6: you should use. You could drop an entire dependency that's
Speaker 6: been in essence twenty twenty one, and folks are just
Speaker 6: now discovering that that exists around time.
Speaker 1: So I just want to point out that Mateo pointed
Speaker 1: out that the Node team made fetch happen, and so
Speaker 1: please stop trying to make fetch happen. Yeah.
Speaker 2: Sorry, we were actually just I think Mattel we were
Speaker 2: exchanging tweets about it or excess about it or what
Speaker 2: was this on on Blue Sky.
Speaker 5: I don't remember.
Speaker 2: More so many options, and so that's number one. So basically,
Speaker 2: if I'm here, I have.
Speaker 1: A question here is there a good place to find these?
Speaker 1: Right the Hey, you might be using a library for this.
Speaker 1: You don't need you anymore.
Speaker 4: Just now, just too Probably it's probably something that we
Speaker 4: should develop and promote a little bit. Okay, maybe like
Speaker 4: this can be a good a good good something that's missing.
Speaker 5: I don't know, this is there.
Speaker 6: There, this is the this is something I would actually,
Speaker 6: you know, Natalia, you know, you know, for like debt
Speaker 6: tools and like the developer experience and like that, because
Speaker 6: those of us are actually working on the APIs, suck
Speaker 6: at the documentation and actually promoting these things. But if
Speaker 6: we can start having the tooling to like promote some
Speaker 6: these things more and say, hey, there's this other thing,
Speaker 6: it might be interesting to look at that. Needia better
Speaker 6: at this.
Speaker 2: A certain way to go about it is to basically,
Speaker 2: if you're looking for certain functionality, check if there's a
Speaker 2: web API for it, basically, and that's really easy because
Speaker 2: for example, you've got MDN and then just check if
Speaker 2: that also exists on note that just that before you
Speaker 2: rush off and NPM install something.
Speaker 3: One of the things we are doing in the project
Speaker 3: is we're ramping up some ambassadors and part of that
Speaker 3: we're coming up with messages we want those ambassadors to
Speaker 3: help promote and that suggestion of like I think we've
Speaker 3: called it something like developing with modern no JS right,
Speaker 3: like to highlight here are the things that are available
Speaker 3: that might not have been available before. It's definitely on
Speaker 3: the list of things that are being brainstormed there.
Speaker 2: Anybody wants to say anything about mono repos before we
Speaker 2: move on to the next one.
Speaker 4: I'm just going to say, use pm PM. This is
Speaker 4: my preference, Okay, I am personal that this is my
Speaker 4: personal preference. Use MPM when you don't need mono repos,
Speaker 4: use PMPM when you need monor repos.
Speaker 5: These matches more or less.
Speaker 4: My yah seems to work fine for other people, but genetically,
Speaker 4: my current status is I'm very happy with PMPM.
Speaker 5: I don't know, Natalia, you what you guys use you
Speaker 5: have a lot of.
Speaker 8: Yeah, No, I second, yeah, I second that I use
Speaker 8: PMPM for monor repos right now, and and PM for
Speaker 8: all the rest.
Speaker 6: Yeah. I agree. There's there's out of all of them
Speaker 6: that's the one that handles this better. Their patterns are
Speaker 6: just actually makes sense.
Speaker 2: So Chuck, maybe move us along to the next one.
Speaker 1: Gonna say, sounds like we've gotten that one. So the
Speaker 1: next one is de risk your dependencies.
Speaker 3: I think it comes back to the part we were
Speaker 3: talking about being intentional, like I think too many people
Speaker 3: pull in a very deep dependency tree without thinking about it,
Speaker 3: and it's you know, once you once you've you've pulled
Speaker 3: things in. Then then we were we talked a little
Speaker 3: bit before, like you almost need to take on the
Speaker 3: approach of like, okay, I'm using this, am I ready
Speaker 3: to help maintain it because like as an organization not
Speaker 3: you know, James mentioned like you should do that because
Speaker 3: it's the right thing to do, but I also think
Speaker 3: it's an organization. It's risk management, right, and most organizations
Speaker 3: that's a big part of them is like how do
Speaker 3: we manage our risk? And as soon as you've pulled
Speaker 3: in the software, it's part of the things you should
Speaker 3: be looking at in terms of managing your risk and saying, well,
Speaker 3: like if we had to switch to something else, could
Speaker 3: we if we had to make a change, could we?
Speaker 3: Is it a healthy project? And you know, and I
Speaker 3: think in near the end there we talk about like
Speaker 3: one way to manage your risk is to support the project,
Speaker 3: either through your people or through funding. And you know,
Speaker 3: so most organizations should should probably invest a little bit
Speaker 3: more time in managing that particular risk.
Speaker 2: Me maybe if the maintainer gets enough support, he won't
Speaker 2: sell or he or she won't sell the project to
Speaker 2: some of the farious third party.
Speaker 3: That that's an extreme example of the case, right, or they.
Speaker 4: Just might not well Eco system Unfortunately he has been
Speaker 4: full of those, okay a couple of times already, So I'm.
Speaker 6: Fortunate, I mean, and that be sold right if the
Speaker 6: maintainer runs out of time to get burnt out, and
Speaker 6: they transition it to somebody without you know, without fully
Speaker 6: vetting who they are. You know that somebody else can
Speaker 6: come in and take care of the project, take advantage
Speaker 6: of the project. Anytime you add a new dependency that
Speaker 6: you don't control or you're not contributing to your adding risk,
Speaker 6: you know. And and if you're if you're bringing in
Speaker 6: a module that brings in you know, one hundred different dependencies,
Speaker 6: you're increasing your risk one hundred fold. So you know,
Speaker 6: you just have to be very intentional about what you're
Speaker 6: bringing in. You have to be very intentional about what
Speaker 6: you're going to support. UH and companies have to stop
Speaker 6: looking at open sources just free software that they don't
Speaker 6: have to do anything with to use. They have to
Speaker 6: help maintain it, or they're bringing or they're just opening
Speaker 6: themselves up to risk. And then if we look at
Speaker 6: like you know, some of the new like federal guidelines,
Speaker 6: you know, it's not just US, you know EU as
Speaker 6: well around s bombs to you know, you know, actually
Speaker 6: being able to produce a an audited list of these
Speaker 6: are the dependencies I'm using. Here's how they're maintained here,
Speaker 6: what the licenses are a lot of folks bring in
Speaker 6: these dependencies without ever thinking about that. But if this,
Speaker 6: if if your module ends up in some being used
Speaker 6: in some regulated industry, you have to be able to
Speaker 6: account for those things and be able to account for
Speaker 6: the risk. So it's it's not just a best practic
Speaker 6: is in some cases, it's an absolute requirement.
Speaker 2: And there's tooling that can help you with this, right.
Speaker 1: Oh yeah, I was gonna say, because it's it's not
Speaker 1: just tooling, but it's tooling that you'll use. Right, And
Speaker 1: for me, it kind of has to be automatic and
Speaker 1: get in my face because I'm lazy and I don't
Speaker 1: go look at it every however often you're supposed to do.
Speaker 1: It's like changing my oil. Right, it's not till the
Speaker 1: light comes on and I go, huh, you know.
Speaker 3: Well that's where I find it a bit surprising. Like
Speaker 3: I don't know however often it is, but every so
Speaker 3: often there's some high profile case where it's the extreme.
Speaker 3: You know, the maintainer goes off and does something to
Speaker 3: their module that they probably shouldn't have. But everybody seems
Speaker 3: surprised that this can happen, right, And like if you
Speaker 3: paid attention, it's sort of something you should know can
Speaker 3: happen in the plan, and so it shouldn't be a surprise,
Speaker 3: And everybody seems to get in a big fuss and
Speaker 3: then after a few months it tails off and it's
Speaker 3: not in your you know, it's not in the news anymore,
Speaker 3: and people forget about it again. So well, I mean,
Speaker 3: that's interesting.
Speaker 6: Just anecdotally. I'm not going to say like you know
Speaker 6: who or what module it was, but you know, this
Speaker 6: is going back and back to twenty fifteen, twenty sixteen,
Speaker 6: one of the most used modules on NPM, and the
Speaker 6: maintainer was quite upset and threatened to just delete everything,
Speaker 6: you know, delete everything off, get up, delete everything off NPM.
Speaker 6: And it came down within minutes that we were able
Speaker 6: to convince them not to do that, and it would
Speaker 6: have broken the entire ecosystem literally they had they had
Speaker 6: they done this, and you know it, Sometimes it just
Speaker 6: comes down to a maintainer being burnt out and not
Speaker 6: feel like they actually have the support. It doesn't have
Speaker 6: to be anything that various. It doesn't have to be
Speaker 6: selling it or somebody else taking over. It could just
Speaker 6: be kind I'm tired of dealing with this.
Speaker 2: Yeah, it is important to mention though that following what
Speaker 2: happened with left PAT that specifically can no longer happen
Speaker 2: with NPM.
Speaker 7: Yeah.
Speaker 1: But I mean I can also see, you know, because
Speaker 1: you guys have talked to about you know, you hand
Speaker 1: it off to a new maintainer or you know, somebody
Speaker 1: otherwise takes it over. But I could see somebody just
Speaker 1: being tired and you know, they know they have a
Speaker 1: problem in their package, and they know they want it fixed,
Speaker 1: and they get a PR that looks like it solves it,
Speaker 1: and it's got something problematic in it. I mean, you know,
Speaker 1: just that easy, you've got something in there that you
Speaker 1: don't want.
Speaker 7: Yeah.
Speaker 3: I think back to Dan's comment, like the I think
Speaker 3: that this has been a challenge or a feature of
Speaker 3: the NOES ecosystem for quite a long time. So things
Speaker 3: have improved, Like you know, the MPM you can no
Speaker 3: longer delete things, and so a lot of that learning
Speaker 3: has actually helped to improve the ecosystem over time. That
Speaker 3: other sort of language ecosystems may be relearning some of
Speaker 3: those lessons along the way.
Speaker 1: So beyond sort of being aware, right, hey, there's an announcement.
Speaker 1: This package where is going to cause you this problem? Right,
Speaker 1: it's got you know, somebody put a back door in it,
Speaker 1: or hey we discovered a zero day, Right, it doesn't
Speaker 1: even have to be that farious, right, you know, the
Speaker 1: best practice has changed and they haven't kept up with it, right,
Speaker 1: and so you know you just need to update it
Speaker 1: or whatever. Beyond that, I mean, I know there's like
Speaker 1: NPM audit, but I kind of have to just run
Speaker 1: that on my machine when I'm running stuff. And you know,
Speaker 1: sometimes I see the notification, sometimes I don't. But are
Speaker 1: there are there tools that while I'm working, are going
Speaker 1: to tell me, hey, you have a problem, like I
Speaker 1: may not have seen the Twitter post or I may
Speaker 1: not have seen the blog post or the announcement or whatever.
Speaker 1: That's going to help me stay up on.
Speaker 9: Depend is the first.
Speaker 8: One, right, the first one you should be looking at,
Speaker 8: and it's going to automatically unless you say, but you shouldn't.
Speaker 7: I don't think that's something you should do.
Speaker 6: And I've that's when I've also become been becoming a
Speaker 6: big fan of the socket stuff, the new process company.
Speaker 2: Soccer.
Speaker 1: I think, yeah, we had them on I'll find the
Speaker 1: episode number and we can put it out there.
Speaker 5: Yeah.
Speaker 3: I think the first part that Italian mentioned is just
Speaker 3: keeping up to date, and there's tools that will basically
Speaker 3: like those keep you help you keep up to date.
Speaker 3: And then there's other tools like the socket one or
Speaker 3: or snack who helped look more specifically.
Speaker 5: At well.
Speaker 4: Mike is not true, depend on also recent discounts for cvs. Okay, yes,
Speaker 4: so g tab will if will push if attacks that
Speaker 4: there was a vulnerability it. Whenever you push commits to
Speaker 4: the report, it will show you that there is there's
Speaker 4: been security problems.
Speaker 6: Okay, to know fantastic.
Speaker 2: You know.
Speaker 4: The important part is that it just works. Okay, you
Speaker 4: don't you have to think you just detects it automatic.
Speaker 4: You just need to use get up. Well if you're
Speaker 4: if you're a developer, you're not developing guitub well you know, okay.
Speaker 6: I think you have to build a habit of not
Speaker 6: ignoring it. I think a lot of folks you know,
Speaker 6: you know, turned on, they're like, okay, it's there, I'm
Speaker 6: not you know, and they just don't act on it
Speaker 6: at all. So I think there, Yes, it can require
Speaker 6: building a new habit.
Speaker 3: Yeah, I guess that comes with a lot of stuff.
Speaker 7: We know a lot of stuff. Yeah, go ahead.
Speaker 3: Back because the CBS are not that great, right, so
Speaker 3: you can get a lot of noise we aren't issues,
Speaker 3: and that that sort of unfortunately reduces the benefits.
Speaker 2: That looks people people ignore medical conditions, like what do
Speaker 2: you expect? You know, people like to ignore things.
Speaker 6: My car has been complaining that it needs and all
Speaker 6: change the past month and I haven't.
Speaker 3: Done it yet.
Speaker 2: So yeah, hm, anything else you want to look. But
Speaker 2: to be fair, people like use MP stuff on NPM
Speaker 2: because they want to reduce their their their workload and
Speaker 2: and they don't consider the the load that they're assuming
Speaker 2: when they do that, and they are sometimes resentful even
Speaker 2: of it. So it is what it is. But yeah, definitely,
Speaker 2: if you're going to be using packages, you need to
Speaker 2: assume responsibility for the packages that you're using.
Speaker 6: And I'll just say, you know, it's not just the
Speaker 6: people get resentful of it. You know, some people look
Speaker 6: at what's published on NPM and they're saying, hey, you
Speaker 6: gave me this thing for free. Cool, You're now obligated
Speaker 6: to support me forever and answer every question I have advancement.
Speaker 6: So no, there is no such thing as enclinement here.
Speaker 6: If you if you're using a package, if it doesn't
Speaker 6: work for you, help me, don't demand that I do
Speaker 6: it for you for free.
Speaker 2: I just want to say that anybody who's listening to
Speaker 2: this podcast and rather than watching it, you're losing half
Speaker 2: of Mattel's.
Speaker 4: I call them vampires. Okay, they have the vampires of
Speaker 4: open source. Okay, and you know your vampires can be
Speaker 4: you know, you need to put out garlic, and you
Speaker 4: can stab them in the heart with a piece of wound, right,
Speaker 4: so that's what you do with them. Okay, So basically
Speaker 4: that isn't I have zero tolerance for vampires in any
Speaker 4: of my records.
Speaker 2: Okay, Yeah. The problem really is that Racula was that
Speaker 2: one vampire and there with the whole world full of humans,
Speaker 2: and here in the open source community it's the reverse
Speaker 2: the majority.
Speaker 4: Fine, but I have zero tolerance like the one that
Speaker 4: they get really toxic about it when you tell you no,
Speaker 4: it's your bug.
Speaker 5: It's not my bug.
Speaker 4: Okay, it's your problem. It's your problem that production, Your
Speaker 4: production is broken, not mine.
Speaker 9: Yes, but the train it's.
Speaker 7: A cultural problem.
Speaker 8: I don't just think it's a cultural problematatic system level
Speaker 8: like we were discussing earlier that developers are not used
Speaker 8: to sharing and sharing the responsibility and the probably we need.
Speaker 2: Yeah, it's a cultural problem that the majority of humanity
Speaker 2: are whiners.
Speaker 1: All right, I'm gonna I'm gonna derail us back to
Speaker 1: our note pillars here and and we're going to move
Speaker 1: along to avoid global variables can figs or singletons.
Speaker 6: Yes, this is a big one. This catches a lot
Speaker 6: of people. And it's not just no I understanding like
Speaker 6: you know, for for for workers a completely different environment.
Speaker 2: It's programming.
Speaker 1: It's a global problem.
Speaker 6: Because global you know, individual like iOS tied to an
Speaker 6: individual request and historical related to requests from another request,
Speaker 6: and it's gonna work. So like here we may explicit
Speaker 6: like don't do this, but yeah, you know we run
Speaker 6: into this all damn time that people just trip themselves up.
Speaker 2: How how is NOE different than than general development? Like
Speaker 2: I like, I've been writing code for I don't know
Speaker 2: thirty years. I remember when I started feeling people were
Speaker 2: telling me my teachers, my my mentors, whatever. Don't use
Speaker 2: globals like what's what's new node? That kind of changes
Speaker 2: the dynamic here.
Speaker 4: A significant portion of the developers that arrive in node Okay,
Speaker 4: it comes from a front end background okay, and or
Speaker 4: reach in aly historically okay, let's put it in the
Speaker 4: jquity days. Okay, all the state was handled in a
Speaker 4: global fashion.
Speaker 5: That don't and yeah they don't. That that comes well
Speaker 5: to the don't.
Speaker 1: Okay.
Speaker 4: The problem is it's one user, okay, one one browser,
Speaker 4: one user, one state.
Speaker 5: Okay, to some extent, it's super simple, Okay, makes total sense. Okay.
Speaker 5: Not JS is not a browser okay.
Speaker 4: One not JS process can handle more than one state
Speaker 4: with one exception, if you deploy on a w S
Speaker 4: lambda or so that you or or workers where one
Speaker 4: request is one state and one user. So you could
Speaker 4: potentially achieat that. And that's what you know, those kinds
Speaker 4: of ens gives it to you because in fact, Javaski
Speaker 4: developer don't seem to be able to understand this principle.
Speaker 6: But if it's not the jobs developers. So when we
Speaker 6: see people, no matter what language you're in, mistakes, yeah,
Speaker 6: and I don't think there's anything you need to know.
Speaker 5: It's probably not. But anyway, the.
Speaker 4: The a lot of a lot of people also a
Speaker 4: part of them they never know anything different.
Speaker 5: They come from a diverse byground. They didn't study any
Speaker 5: of this stuff. Okay.
Speaker 4: The other part is a group of people that we
Speaker 4: used to do all software engineering and do a lot
Speaker 4: of interface and a lot of things come from a
Speaker 4: javaor dot m background that when they swop to know
Speaker 4: they throw package at all of that and throw it away.
Speaker 4: And when you show them how you can you know,
Speaker 4: you can actually use this pattern to build a system
Speaker 4: that is modular. And oh so I can do all
Speaker 4: the things that I was used to do in Java
Speaker 4: or dot nety No, yes you can, and they're just
Speaker 4: I didn't know.
Speaker 1: So so my question is like, what exactly is a
Speaker 1: solution here?
Speaker 6: Right?
Speaker 2: Is it?
Speaker 1: Is it like importing environment variables is.
Speaker 8: Right?
Speaker 1: But I mean I mean some things you do have
Speaker 1: to bring in through configus, right, I mean they are
Speaker 1: essentially going to be globally available. Yeah, I strike keys
Speaker 1: or API keys or you know you set node and
Speaker 1: to production and right, and that.
Speaker 6: Kind of changes the game. So so stuff like that, Yeah,
Speaker 6: what big one Pensy intection is the big one for modules.
Speaker 6: You know, like a lot of some modules and stuff.
Speaker 6: You know, when you go to require something, you get
Speaker 6: back some single thing rather than that is your return
Speaker 6: a factory that you know that you can use to
Speaker 6: create your state management. So I think I think there
Speaker 6: are a number of things. Some of these are discussed
Speaker 6: in the in the blog post and tailor about them,
Speaker 6: but the actually is the big one. You want to
Speaker 6: actually say, you know, for this particular bit of code,
Speaker 6: this is what I want to make available to that,
Speaker 6: not just have it generally available for everyone to access.
Speaker 2: Also, you know, if if all your objects are singletones,
Speaker 2: it's not object oriented programming. And all the data within
Speaker 2: a global single tone, all the fields within a global
Speaker 2: single tone, certainly all the public properties within a global
Speaker 2: signal tones are affectually all globals. So if I'm saying no,
Speaker 2: I don't have a hundred globals, I have just one global,
Speaker 2: but it has one hundred public properties, then you've got
Speaker 2: one hundred globals.
Speaker 8: Yes, And in.
Speaker 2: Genera where and in general beware also mutable state, it's
Speaker 2: certainly global.
Speaker 1: Mutable states.
Speaker 6: Avoid it all costs if you can. And this is
Speaker 6: the problem things like you know process do you know whatever?
Speaker 6: In node it's a global, it's a global. A lot
Speaker 6: of folks will find it are using that for feature detection. Right,
Speaker 6: they'll say, hey, if process exists and obviously i'm running
Speaker 6: a note, Well no, because process now exists and you know,
Speaker 6: and it just and find it exists in workers. Okay,
Speaker 6: Well instead of using process, let me look at you know,
Speaker 6: process dot whatever property. Well, if the run times start,
Speaker 6: these other run times start. Also adding that relying on
Speaker 6: these globals, just the existence of these globals, just to
Speaker 6: depend on where you're at, everything still breaks. You're just
Speaker 6: shifting the problem. It's going to break somewhere else. So
Speaker 6: there's lots of problems with these, with these ideas of
Speaker 6: having these globals. And it's not just whether you're storing state,
Speaker 6: it's but decisions are you making based on existence.
Speaker 2: Of the global it's us their agent strings all over again.
Speaker 6: Yeah, only maybe even worse because there's so many different
Speaker 6: ways of doing it.
Speaker 4: Oh man, So the way the worst pattern here is
Speaker 4: those applications that then they are fully configurable US using
Speaker 4: environment variables. Okay, and the environment variables are pride into
Speaker 4: a thousand different files, so you don't know what are
Speaker 4: the confusion, and each one has a different default, and
Speaker 4: you don't know what each of anyone controls and the
Speaker 4: only way to know is just grab the full codebase.
Speaker 2: Mm hmm.
Speaker 5: It's a nightmare, okay, and I don't you know there's
Speaker 5: a nightmare.
Speaker 4: So you want to take when you're your application starts,
Speaker 4: you want to take your environment variable.
Speaker 5: So you're conflict.
Speaker 4: You pass the thing you'd get the values, and then
Speaker 4: you pass it down each single application.
Speaker 2: Now you've got a recommendation especially sorry.
Speaker 8: Especially, do not use schools if you're going to publish,
Speaker 8: like we were suggesting earlier, for everyone to consume.
Speaker 9: Yes, let's try.
Speaker 2: Yeah, you're just spreading your bad habits around and impacting everybody.
Speaker 6: I would say that module, you know, any dependencies that
Speaker 6: you're bringing in, do not touch globals. I mean, if
Speaker 6: you're consuming globals like global APIs like URL, fine, do
Speaker 6: not mu take global state from the module. Period.
Speaker 1: So you kind of said that there might be configures
Speaker 1: throughout your app. That is the issue that you have
Speaker 1: your configurations that may be spread across different places where
Speaker 1: you get them from. Or is the issue that you
Speaker 1: have a lot of places where it changes the way
Speaker 1: your code works.
Speaker 2: We're both I think both Socially, you manage sort to interrupt,
Speaker 2: but I'm really am trying to to understand, James, where
Speaker 2: you get what you're getting at? If I've got like
Speaker 2: what I like effectively global configuration, Like there are certain
Speaker 2: configuration flags that impact the behavior of my entire application.
Speaker 2: Would you rather have one module responsible for all that
Speaker 2: global figuration and everybody gets injected with it, or would
Speaker 2: you rather that each model is just responsible for the
Speaker 2: configuration that directly pertains to what that module does, Like,
Speaker 2: what would be your approach here?
Speaker 6: My approach would be that the application should collect whatever
Speaker 6: configuration is available and inject that into the modules. So
Speaker 6: the module itself should not be looking at processing. It
Speaker 6: should be relying on what arguments are passed to it
Speaker 6: from the application.
Speaker 1: So I'm just going to ask, because if there are
Speaker 1: a lot of places where your configuration can change the
Speaker 1: way that the code flows through your application, it almost
Speaker 1: sounds like feature flags, And I know a lot of
Speaker 1: people use those. So are you arguing against feature flags
Speaker 1: or do you see those.
Speaker 6: Differently the same different I think it comes down to
Speaker 6: how they're injected into the module.
Speaker 3: Okay.
Speaker 2: The problem is that sometimes it can lead to having
Speaker 2: to pass things through a lot of function calls, like
Speaker 2: You're trying to get a flag way down, and now
Speaker 2: you've got to pass it through a lot of you know,
Speaker 2: a colls B, colls C. Now I have to add
Speaker 2: the parameter to all of these functions which really don't
Speaker 2: care about this feature flag just to get it all
Speaker 2: the way down. So I'm saying, hey, I'm going to
Speaker 2: clean the code by just making it global. Uh, and
Speaker 2: now I can access it from from wherever I need to.
Speaker 2: It's kind of like the problem that React tries to
Speaker 2: solve with context in a way.
Speaker 6: Yeah, well, I mean we have the same Like that's
Speaker 6: also where acinc Global storage kind of kind of comes
Speaker 6: into play, where you can use acent local storage to
Speaker 6: avoid that, you know, having to pass it through each layer,
Speaker 6: but you still have to make the acinc local storage
Speaker 6: variable itself available, you know, to the various places that
Speaker 6: are So how do you do that? It's it's it's
Speaker 6: not a problem free approach. It has its own challenges.
Speaker 6: Whether you have to pass this thing down or make
Speaker 6: some you know, make some things global and other things not.
Speaker 6: You have to be very intentional and plant it out
Speaker 6: very carefully. But as a whole overall, right, relying on
Speaker 6: dependency injection is going to be far better a pattern
Speaker 6: in a far more maintainable pattern free application than allowing
Speaker 6: modules to just arbitrarily access and modified level state.
Speaker 2: Yeah for sure, then you need to somebody modified my
Speaker 2: state and I have no idea who.
Speaker 1: My cheese?
Speaker 2: Yeah, yeah, I do want Before we move on to
Speaker 2: the next one, you kind of made an interesting assertion
Speaker 2: in this pillar which is always set no d V
Speaker 2: to production. Can you elaborate why? What's you know? Why?
Speaker 2: And why is it?
Speaker 6: Like?
Speaker 5: This is an old battle, This is an old battle
Speaker 5: of mine? Okay. Now all of these comes from one problem. Okay,
Speaker 5: for developers.
Speaker 4: If I ask ten developers what the development environment is,
Speaker 4: they tell Mike Black. If if you ask ten ops people,
Speaker 4: they say, oh, it's some service running somewhere where the
Speaker 4: developer test that code.
Speaker 5: Okay, that's the source of the problem. Okay. They we
Speaker 5: use the same the same terms for two different things. Okay.
Speaker 4: Now this means that somebody, somebody bright mind started to
Speaker 4: put published a module called muh config in MPM and
Speaker 4: then that loads you the now the score environment variable
Speaker 4: for loading up the conflict file. However, some libraries in
Speaker 4: like Express for example, React, than others changes their behavior
Speaker 4: based on the northern.
Speaker 5: The score en of environment variable being set to production.
Speaker 4: Now, if you're loading the conflict for your service environment
Speaker 4: based on that variable, you are essentially your staging environment
Speaker 4: or anything that is not production.
Speaker 5: Absolutely you will have massive issues.
Speaker 4: And that confic module is downloaded so many times, okay,
Speaker 4: which is unbelievable.
Speaker 5: And frankly, it should not be used. Okay.
Speaker 4: I'm very happy to stand here making these recommendation. So
Speaker 4: don't use that module if possible.
Speaker 5: Okay.
Speaker 1: So when you say always you mean in development as well?
Speaker 4: Yeah, no, I mean in development is the only moment
Speaker 4: where you don't set it very often. But whenever you
Speaker 4: want to do any testing that is relevant to what
Speaker 4: production looks like, you need to set it to production, even.
Speaker 5: If it's a staging environment.
Speaker 4: So oh wait a three, I am using something that
Speaker 4: controls my environment. That's called an environment. I said it
Speaker 4: to production even if it's a staging environment. Yes, this
Speaker 4: was such a bad term to begin with, okay, and
Speaker 4: such a massive headache pain that unfortunately.
Speaker 5: We're stuck with. So and I'm sorry, like, please.
Speaker 4: Don't use again, don't use, don't cload the configuration based
Speaker 4: on that valuable because it's a bad idea.
Speaker 1: I've had that bite me squarely in the rear end before.
Speaker 1: So all right, just in the interest of time, we're
Speaker 1: going to move to the next one. It's handled errors
Speaker 1: and provide meaningful logs. I'd stand up and screen yes,
Speaker 1: because I had this one hurt me too. But where
Speaker 1: where you guys.
Speaker 2: For me that?
Speaker 6: I mean just the title of this one is is
Speaker 6: I think? So it's like, that's that's good enough the
Speaker 6: provide meaningful logs. I think I think this is not
Speaker 6: specific to note. You know, we've all had examples of
Speaker 6: run times where it's just like, hey, error happened. Cool?
Speaker 6: Where how?
Speaker 2: What? What? What?
Speaker 6: Actually is that take the time? People have to understand
Speaker 6: that the errors that their their system produces is part
Speaker 6: of the contract, part of the a P. I need
Speaker 6: to be as intentional about the design of errors as
Speaker 6: they are about the the syntax or the or the
Speaker 6: signature of the functions that the calling they're exposing errors
Speaker 6: are a PI I designed them accordingly.
Speaker 2: If your server crashes in the middle of the night
Speaker 2: and you're told about it in the morning after it's
Speaker 2: been restarted, will you able to you will you be
Speaker 2: able to do anything about it. If your answer is no,
Speaker 2: then you've got the problem.
Speaker 6: Yeah, it's.
Speaker 1: It's it's so rough when you yeah, you have this issue.
Speaker 1: And then essentially you have to go keep going back
Speaker 1: and modifying what gets logged to try and figure it out,
Speaker 1: because you can't duplicate it in development and you don't
Speaker 1: have enough information in your logs to figure out how
Speaker 1: it happened in production. And sometimes there are going to
Speaker 1: be bugs that way, no matter how good at this
Speaker 1: you are. But for heaven's sake, you know, if you
Speaker 1: if you know that something unexpected might happen there, you
Speaker 1: know you can set yourself up for success by just
Speaker 1: being aware and then having a good API and a
Speaker 1: good approach to logging errors.
Speaker 2: Look, you might not have the proper, the sufficient logs
Speaker 2: the first time around, because you know, obviously there's a
Speaker 2: limit on how much you can log and how and
Speaker 2: you don't want to be, you know, excessively verbose, and
Speaker 2: they're usually also costs associated with logging. But you know,
Speaker 2: at the very least you want to be able to
Speaker 2: change log level on some so that the next time
Speaker 2: it crashes at least then you'll you'll you'll have sufficient
Speaker 2: context if you now have to start adding new logs.
Speaker 2: It's going to be a pain.
Speaker 6: M oh yeah, definitely. In this In the in the
Speaker 6: post it there's a section provide meaningful logs. Again, it
Speaker 6: goes back to being intentional, treating this as part of
Speaker 6: your API, in a part of your contract. It's possible
Speaker 6: to go way overboard logging completely useless information that completely
Speaker 6: drowns out the useful bits of information. So it's like
Speaker 6: it's as much of a decision of what not to
Speaker 6: log as it is what to log and where and where.
Speaker 6: You know, there's a whole science to it, but it
Speaker 6: takes time to get right. But you have to put
Speaker 6: a lot under this point, and most people don't.
Speaker 2: And you need to think about what logs at what levels,
Speaker 2: and can you control levels like globally or for module
Speaker 2: and stuff like that, or at least per service and
Speaker 2: stuff like.
Speaker 6: That, and provide details, provide enough details that you can
Speaker 6: filter out the noise that's not relevant to a particular investigation.
Speaker 1: I was going to say, there are libraries that give
Speaker 1: you kind of a default format to start from that
Speaker 1: are typically better than the default logging deal that you
Speaker 1: get from what you're beginning with. And so you know,
Speaker 1: have a look at those, figure out what they're doing,
Speaker 1: and then just just be intentional. From there, I may
Speaker 1: also need to know this.
Speaker 8: Yeah, if you're a developer tool developer, you also need
Speaker 8: to make sure your logs are not two verbals that
Speaker 8: go back to the developer with the right feedback and
Speaker 8: not a lot of noise that is useless to.
Speaker 1: Trouble shoot anything else.
Speaker 6: On that one, I will say, talking about the cost
Speaker 6: of logging, it's a it's a fairly old article at
Speaker 6: this point, but when Mattel and Avemark Clemens and Supper
Speaker 6: Working then started on Pinot, there's some research on the
Speaker 6: cost of logging and performance cost of blogging that even
Speaker 6: though the exact numbers and stuff may be different today
Speaker 6: than what they were back then, it is still an excellent,
Speaker 6: excellent read. Mattel, you can provide me with a link
Speaker 6: to that. I don't have a handy, but.
Speaker 5: Of course I can. It's very old, it's very old, but.
Speaker 6: I consider it. I consider it kind of part of
Speaker 6: the must read collection of stuff for understanding a lot
Speaker 6: of this stuff. It really breaks down why there's the
Speaker 6: cost of why you have to be intentional about this stuff.
Speaker 2: It is so uh. And one more thing I see
Speaker 2: in the article Mattel that you recommend the Pino as
Speaker 2: a library to use for logging.
Speaker 5: Yeah, well that's what.
Speaker 4: They David myself wrote all those year backs, so that
Speaker 4: logging was the major bottoneck of most more the applications,
Speaker 4: which is incredible. Like you know, it's so the first
Speaker 4: one was logging, okay, and the second one was was expressed.
Speaker 4: So I created Pino and then I created Fastify okay.
Speaker 4: So that that was my journey and the optimizing the ecosystem.
Speaker 4: So I started getting one, then I move, I moved
Speaker 4: from there, moved to the next one. Okay, done essentially,
Speaker 4: And no, it's it's very problematic. Okay, there's a lot
Speaker 4: of like clogging is very hard. It's a very hard topic. Okay,
Speaker 4: either it's a big problem, is a big pain, or
Speaker 4: it's absolutely not okay, if you have a certain scale,
Speaker 4: is a massive pain.
Speaker 2: Oh yeah, for sure. Like I I three the three
Speaker 2: latest companies that I've worked, including the latest one size
Speaker 2: and so I currently work I. You know, you you've
Speaker 2: got the develops person coming up to you and saying,
Speaker 2: why have we got a billion logs every day? Do
Speaker 2: you really need all those logs.
Speaker 5: Yeah, pretty much. But it's also it's actually it's actually
Speaker 5: very hard.
Speaker 4: It's a very hard problem to fix, okay, and to
Speaker 4: be able to achieve the right level of granularity and everything.
Speaker 4: So with Pino we have reached a very good I
Speaker 4: think good balance. It works very well out of the
Speaker 4: bobs with good defaults, okay. But it can also be
Speaker 4: tuned down for your app to the exact what you need, okay.
Speaker 4: And you know, it has very very you know, fine
Speaker 4: grained configuration that you can put it in, and it's
Speaker 4: very important that you do those things when once you
Speaker 4: reach a certain level of production.
Speaker 6: For me, though, you know, using the tool with one
Speaker 6: thing and I would recommend, you know, absolutely hands down.
Speaker 6: But for me, it mostly comes down to being aware
Speaker 6: of what you're logging and where the costs are. If
Speaker 6: what you're logging or a bunch of large objects areting
Speaker 6: it Jason serialized, understand that there's a cost to Jason serialization, right,
Speaker 6: and if you're sending these massive objects into this.
Speaker 5: Thing, come on, marshaling. Marshaling is not free.
Speaker 6: But you know, we end up with these with with
Speaker 6: with this code. I've seen this time and time again
Speaker 6: where you have the this this logging logic and like, hey,
Speaker 6: we're following the best practice. We're logging on these levels.
Speaker 6: Well okay, that level is not activated. Why are you
Speaker 6: still constructing this massive object, you know, unconditionally passing it
Speaker 6: off to their understand you know, when that has its
Speaker 6: own costs, and you know, folks need to stop and
Speaker 6: think about what they're looking and why and how not
Speaker 6: just what tool they're using, and understand this stuff has.
Speaker 6: That's a definitive cost.
Speaker 2: I'm sometimes so analo on those things, but I guess
Speaker 2: it's my mentality going back to the good old days
Speaker 2: of C and C plus plus and stuff like that. Uh,
Speaker 2: it's it really bugs me when I see something being
Speaker 2: computed for no for absolutely no reason.
Speaker 1: My brain sack faulted. When you said the good old
Speaker 1: days with C and C plus plus.
Speaker 2: Guys, I have to I have to drop off because
Speaker 2: there are sirens here. So thank you.
Speaker 1: All right, let's let's talk API specifications here real quick. So, yeah,
Speaker 1: who wants to tackle this one?
Speaker 7: Yeah?
Speaker 9: I'm pretty opinionated on this, and mostly because of what
Speaker 9: James just said.
Speaker 7: The contract is essential.
Speaker 6: You need to have it.
Speaker 9: You need to understand how you're going to collaborate with
Speaker 9: other people.
Speaker 8: Mostly now that that everyone is on the couple services
Speaker 8: or a lot of the applications. Fully, you're moving into
Speaker 8: that kind of architecture. To to make sure that you
Speaker 8: have the right governance, you need to have API contracts first.
Speaker 8: So that's one hundred.
Speaker 2: It must.
Speaker 1: Yeah, So you you guys in this one, you recommend
Speaker 1: either open API or graph ql. You said that they
Speaker 1: it depends on what you want, right, They have different strengths.
Speaker 1: So yeah, do you do you want to kind of
Speaker 1: talk a little bit about that, and then I'm really
Speaker 1: curious about generating clients and types because anyway, go ahead
Speaker 1: and answered that first part and then and then we
Speaker 1: can get into the clients and types of questions there.
Speaker 5: Let me take that very very briefly.
Speaker 4: Then I probably passed the ball to Natalie because she
Speaker 4: has a different opinion for me.
Speaker 1: So it's a nerd fight.
Speaker 5: Yeah.
Speaker 2: So the.
Speaker 4: An API is great. It provides the map to rest okay.
Speaker 4: So if you know how your systems are going to
Speaker 4: be composed and used, okay, this is great. However, they
Speaker 4: still suffer from, you know, the level of granduality that
Speaker 4: you're doing with rest okay. So it means that in
Speaker 4: order to achieve a certain a certain function, a certain
Speaker 4: central behavior, they will need to developer using those APIs,
Speaker 4: we need to issue two, three, four or five different calls, okay,
Speaker 4: especially from and these adds a lot, can add a
Speaker 4: lot of latency.
Speaker 5: That's the problem in to fights the data that they need.
Speaker 4: To get the data that they need will graph you
Speaker 4: l you can actually do that with one single pass
Speaker 4: and have that logic done on the server side, okay,
Speaker 4: which I don't want to go into the intricacy of
Speaker 4: implementing that correctly. But the different news case is if
Speaker 4: you know, if you don't know how your system is
Speaker 4: going to be read and accessed, graphical is a great system,
Speaker 4: great way to provide all discoverability and easy way to
Speaker 4: consume the data.
Speaker 1: Okay.
Speaker 4: While my undergeneric understanding is that using open API can
Speaker 4: lead to more performance implementations and that are easier to
Speaker 4: scale genetically, so at the cost of latency. So you see,
Speaker 4: there is there is a trade and Natalian, I know
Speaker 4: that you prefer you have a different opinions to you.
Speaker 7: No, No, I mostly agree with what you say, like
Speaker 7: I like with everything else. You need to evaluate your
Speaker 7: trade offs.
Speaker 8: What are you what do you want to have cashing?
Speaker 8: Do you want to have a more granular or underfetching, yes,
Speaker 8: then go with with a certain pattern or an other.
Speaker 8: I am I am one hundred percent.
Speaker 9: Sure that even even if you're doing graph cul, you
Speaker 9: need to have a contract no matter what and generating
Speaker 9: your clients. It's right now.
Speaker 7: A possibility.
Speaker 9: Generating your client on top of the contract is very affections.
Speaker 1: So that that kind of leads right into this next part,
Speaker 1: which is generating clients and types. So I have to
Speaker 1: admit I've mostly unrest where I've done graph ql, Like
Speaker 1: I had to build the resolvers and stuff like that.
Speaker 1: It just felt like a lot of extra work to
Speaker 1: get that graph qu all the work. I mean, if
Speaker 1: I was doing front end that consumed graph ql a
Speaker 1: lot of times it was just magic, right, And so
Speaker 1: I felt like the trade off may or may not
Speaker 1: have been worth it. Am I looking at this wrong?
Speaker 1: Or is there something I just haven't seen there?
Speaker 4: Graphql okay removes removes a lot of the like if
Speaker 4: you okay with graph ql, which is something it's a
Speaker 4: fantastic system. If you have a lot of disjunted teams
Speaker 4: that do not talk with anyonet to minimize the incommunication
Speaker 4: between them.
Speaker 5: Okay. Essentially it's a tool that enables Okay, it is
Speaker 5: your graph celent point.
Speaker 4: It's my problem to maintain that, the team that produces it,
Speaker 4: maintaining and keeping it up and keeping it performance, which
Speaker 4: it might be very much in trouble in doing so.
Speaker 4: But it's a business choice, okay. And then consumers can
Speaker 4: get that. The consumers can just you know, they feel
Speaker 4: the magic. Okay, somebody feel the pain. Somebody else feel
Speaker 4: the magic.
Speaker 1: Okay.
Speaker 4: With with the rest and open API, you you probably
Speaker 4: it's less my That's what I'm saying.
Speaker 5: You can.
Speaker 6: Yeah, yeah, get a little bit of tighter coupling with.
Speaker 5: The genetically leads to tighter couple.
Speaker 6: Which is which, which is ironic given REST was originally
Speaker 6: intended to avoid the tighter coupling, but you still end
Speaker 6: up with that.
Speaker 1: Yeah.
Speaker 6: So, but I think I think to the highest point,
Speaker 6: the most important thing is having a contract. And you know,
Speaker 6: if you can generate code from that contract automatically, cool,
Speaker 6: all the better. But you have to start with the contract,
Speaker 6: whatever that is. And you can write the API contract
Speaker 6: just in a markdown document and say this is how
Speaker 6: the thing works, but you have to start with the
Speaker 6: contract first.
Speaker 1: Yeah, is there anything you wanted to add on those points?
Speaker 6: Or I think in Italian that they covered it perfectly.
Speaker 6: You know, there are trade offs you can generate. Cool,
Speaker 6: it's gonna be better for everyone. Whichever one you use
Speaker 6: depends on what your specific requirements are.
Speaker 1: Gotcha. There was a section here about API first versus
Speaker 1: code first, so that.
Speaker 5: Is a different in pattern.
Speaker 4: So uh, there's a lots of debate between all the
Speaker 4: people that do contract based development that they should start
Speaker 4: with this design the side big design session where the
Speaker 4: contract of the API is defined, okay, and then the
Speaker 4: people writing consuming it go their merry way, and then
Speaker 4: the people writing the the API go their merry way.
Speaker 5: Oh and that said, okay, bye, Natalia, I don't.
Speaker 1: Know, she's gone, and she said she had a hard stop.
Speaker 4: Yeah, and basically one when one way, the other one
Speaker 4: when the other way. Okay uh, and then when they
Speaker 4: try to meet in the end, it never works.
Speaker 6: Okay, I I.
Speaker 5: Don't know.
Speaker 8: I have.
Speaker 6: Person, and I'll work back to the A P I.
Speaker 6: But then I won't finish the code until the A
Speaker 6: contract is figured out so it can work.
Speaker 4: It's yeah, my genetically recommend My my experience is the
Speaker 4: contract is ready when the implementation that implement that contract
Speaker 4: is ready is final. Okay, you cannot finalize that, and
Speaker 4: therefore I am more or less saying that you know
Speaker 4: that and that.
Speaker 5: But the key challenge there is you need to keep
Speaker 5: to uphold the contract. Okay.
Speaker 4: Once you stubish the contract, you need to not break
Speaker 4: the contract. Very important because if you start breaking that.
Speaker 4: This is one of the bigger process of downtime. Somebody
Speaker 4: changed an API and said, oh, but these these things
Speaker 4: is now required it's not. Or these things was optional
Speaker 4: before and now well these things was required before is
Speaker 4: now optional whatever? Okay, and then the crash that starts
Speaker 4: opening all over the system, and one little change in
Speaker 4: a tiny micro service can bring down the full the
Speaker 4: full fleet.
Speaker 6: Either that or you end up with tons of technical
Speaker 6: debt and outdated code and obsolute stuff that you have
Speaker 6: to keep around.
Speaker 1: All right. Well, just to wrap up, is is there
Speaker 1: kind of an overarching theme or any messages that you
Speaker 1: want to kind of add to this or do we
Speaker 1: just for me? For me?
Speaker 6: The overarching theme is be intentional, be aware, like like
Speaker 6: pay closed attention to thing you're doing, whether it's breaking
Speaker 6: down the tasks so you don't let in the event loop,
Speaker 6: to whether it's bringing in a new dependency to you know,
Speaker 6: how you're designing your API. You have to stop and
Speaker 6: think about what you're doing.
Speaker 3: Yeah, and pretty much all the ones in the list
Speaker 3: that's the like, think about what you're doing. And this
Speaker 3: is almost a nice checklist to go through to say, like,
Speaker 3: have we been intentional enough to we plan what we're
Speaker 3: doing in each of these places and go from there.
Speaker 1: Yeah, all right, good deal. I'm not sure if mateo
Speaker 1: is frozen or.
Speaker 5: And I need really need to drop now, Okay, I.
Speaker 6: Break conversational.
Speaker 1: Yeah, well I'm gonna throw in some picks. I don't
Speaker 1: know if you want to do that too, Michael, but yeah,
Speaker 1: let me jump in here real quick with my picks,
Speaker 1: and then you can go ahead and throw in yours,
Speaker 1: or if James is going to stick around, he can
Speaker 1: do that too. But I got like, I got like
Speaker 1: three minutes, so okay, well maybe you can go first.
Speaker 1: I'm guessing you did picks last time.
Speaker 6: Yeah, it didn't.
Speaker 2: Watch time.
Speaker 6: I'm miss going to say something, you know, super simple,
Speaker 6: step away from the computer, go outside, talk to people,
Speaker 6: you know, you know, don't get too wrapped up and stuff,
Speaker 6: especially folks in the US. You know, things are kind
Speaker 6: of still, you know, you know, kind of rather there's
Speaker 6: quite a bit of turmoil and stuff. So just step away,
Speaker 6: take a break.
Speaker 1: That's it. Yep, It's good advice anytime of the year.
Speaker 6: I'm gonna go ahead.
Speaker 1: Okay, thanks for coming, James. All right, I'm gonna throw
Speaker 1: in my picks here. So my first pick I always
Speaker 1: do a board game pick. This last weekend, I was
Speaker 1: at a board game convention and I was teaching people
Speaker 1: the hot games. So my friend picked the games and
Speaker 1: we taught them at you know, for free, at the
Speaker 1: tables at the game at the game convention. So I'm
Speaker 1: just gonna pick one of those games. The game that
Speaker 1: I'm picking, And this was a super fun game. It's
Speaker 1: it was relatively simple to pick up. You know, I
Speaker 1: could explain it to people in like ten minutes, and
Speaker 1: you know, it takes about forty five minutes to play.
Speaker 1: You can play two to four players. It's called Gnome
Speaker 1: Hollow and effectively, I'm not going to give you the
Speaker 1: ten minute spiel. I'm going to give you the two
Speaker 1: minute spiel. And then if you want to go learn it,
Speaker 1: you can. Board game Geek weights it at two point
Speaker 1: one seven, so it's it's a fairly easy casual game
Speaker 1: or game. The way you play it is you are
Speaker 1: making like circles of like mushroom circles, right, so you
Speaker 1: know there's the kind of mythological you find a circle
Speaker 1: of mushrooms and it's you know, fairy something I don't
Speaker 1: I don't know, but anyway, so you're making mushroom rings
Speaker 1: and then you harvest the mushrooms from the rings, you
Speaker 1: take them to the market, you sell them for points.
Speaker 1: As you create more rings, you also just cover different
Speaker 1: kinds of wildflowers, and so you can collect the wild
Speaker 1: flowers and those are worth points. And then as you
Speaker 1: complete rings, you also move markers down onto your board.
Speaker 1: That gives you rewards, and the number of markers you've
Speaker 1: moved down is also a way of scoring points. Those
Speaker 1: are the three things that score at the end of
Speaker 1: the game. The points you've bought, or the points you've
Speaker 1: sold your mushrooms for the amount of wildflowers different wildflowers
Speaker 1: you've brought into your board, and then the number of
Speaker 1: rings you've completed. Basically it was super fun. Once you
Speaker 1: play around or two, it's like, oh, okay, I totally
Speaker 1: get how this goes. And so the rest of it
Speaker 1: is just figuring out which strategies you want to go for, Right,
Speaker 1: Am I going to maximize on flowers on rings or
Speaker 1: on you harvesting and selling mushrooms? And yeah, it was
Speaker 1: really really fun. Of all the games that we taught,
Speaker 1: this one was probably my favorite. I did buy one
Speaker 1: of the other games before the Game Board Game Convention
Speaker 1: because I liked it so much, but I've picked it
Speaker 1: on the show before. It's Challengers, So anyway, I'm gonna
Speaker 1: pick that one. No im hollow, And like I said,
Speaker 1: it's forty five minutes to an hour game, and yeah,
Speaker 1: the artwork on it is amazing. That always makes it
Speaker 1: more fun if it's got a good theme and it
Speaker 1: all kind of is cohesive. A couple of other things
Speaker 1: I'm gonna pick. I've been watching the show Reacher and
Speaker 1: I've been enjoying that. I just like the way that
Speaker 1: Jack Reacher essentially is I'm gonna do the right thing
Speaker 1: that I think is the right thing, and you can
Speaker 1: all just go pounce end and you know, if you
Speaker 1: get in my way, I'm gonna make you wish you
Speaker 1: hadn't you know, I just I don't know. I like
Speaker 1: to take no prisoners. I'm gonna find the truth approach
Speaker 1: to life. So you know, this kind of takes it
Speaker 1: to an extreme. It's kind of a violent show. So
Speaker 1: if that's not your cup of tea, don't watch it.
Speaker 1: You're right, it gets a little bit. Yeah, just violent.
Speaker 1: So I'm gonna pick that and then the last pick
Speaker 1: along the lines of what James was picking. You know,
Speaker 1: we just had the elections here in the United States.
Speaker 1: I know a lot of people have feelings about it.
Speaker 1: I've taught you know. I live in Utah, where red state.
Speaker 1: A lot of people are pretty happy that you know,
Speaker 1: Trump won and that you know, the House and the Senate.
Speaker 1: But then I see people kind of taking to task
Speaker 1: or making fun of people who are sad because you know,
Speaker 1: theirs I didn't win, and I'm not about that. I
Speaker 1: think some of the ways that people are reacting or
Speaker 1: overreacting to it is amusing. But I just keep that
Speaker 1: to myself because at the end of the day, it's
Speaker 1: not worth it to demonize or you know, make somebody
Speaker 1: feel bad because their side didn't win. So I just
Speaker 1: encourage everybody to be kind to each other. And then
Speaker 1: the folks on the other side, because I do see
Speaker 1: the posts where it's like, you know, my my family
Speaker 1: all voted for Trump and I'm not ever going to
Speaker 1: talk to him again. It's like, guys, don't do that,
Speaker 1: right either side, don't do that. You know, everybody has
Speaker 1: reasons why they voted the way they voted. Some of
Speaker 1: them are good, some of them are bad. You know,
Speaker 1: you think that they see what you see and then
Speaker 1: they voted the other way. Anyway, that's generally not true.
Speaker 1: I think we all mostly want to be you know,
Speaker 1: prosperous and happy and be able to take care of
Speaker 1: our families and things like that. So, you know, just
Speaker 1: give everybody the benefit of the doubt. And you know,
Speaker 1: if you're not up for having the conversation with the
Speaker 1: people you care about, then don't. But if you can,
Speaker 1: and you can come to understand a little bit more
Speaker 1: of I was really scared that this was going to
Speaker 1: happen if Trump or Harris got elected, you know, or
Speaker 1: I really care about this issue, and so I voted
Speaker 1: you know, maybe a single issue or mostly a single
Speaker 1: issue at least, then you can kind of see where
Speaker 1: people are coming from, and a lot of times you
Speaker 1: see the humanity in them anyway. So I'm just going
Speaker 1: to encourage that I'm not really shy about where I
Speaker 1: come down on this stuff, so you can I'll probably
Speaker 1: guess it, but that's not what this show is about.
Speaker 1: And I really feel like the best thing we can
Speaker 1: do at this point is just kind of come together,
Speaker 1: make sure we understand each other, and then take care
Speaker 1: of each other. So anyway, Michael, what are your picks?
Speaker 3: I'm just going to have one really quick one. Over
Speaker 3: the years, I've always wished I could like print you know,
Speaker 3: heads for the little Lego.
Speaker 5: Man, you know, to play around with, and uh, that
Speaker 5: sounds awesome.
Speaker 6: Yeah.
Speaker 3: Maker World, which is from Bamboo Labs. They actually have
Speaker 3: recently they've got like, uh I think it's probably Ai
Speaker 3: based or something, but they've got like a new a
Speaker 3: new offering where if you if you log in, you
Speaker 3: can upload a picture and it basically will create you
Speaker 3: a three D printable, uh you know, head of head
Speaker 3: of that you can then adjust and tinker with just
Speaker 3: like any other three D print. So pretty cool.
Speaker 1: I want to do that for all my kids.
Speaker 3: Now, there you go. Well, now go to maker World
Speaker 3: and you can. They've got they make it easy, so
Speaker 3: it's pretty cool.
Speaker 1: Yeah, we're a Lego family here for sure. So awesome. Well, Michael,
Speaker 1: I was going to ask this of everybody else, but
Speaker 1: they're all gone. If people want to connect with you,
Speaker 1: where do they find you?
Speaker 3: I you can follow me on Twitter MH Dawson one.
Speaker 3: Also on Blue Sky at MH d Austin without the
Speaker 3: one because I managed to get that one first, and
Speaker 3: or you know, in Getthub very active in that the
Speaker 3: no project GetUp.
Speaker 6: So that's the best places.
Speaker 1: Awesome. I just barely joined Blue Sky. I'm cmax w
Speaker 1: just like I am on Twitter. I will say that
Speaker 1: I am looking to set up accounts for the shows,
Speaker 1: so keep an eye out for JavaScript Jamber. It'll probably
Speaker 1: be jass Jamber unless that's taken. So anyway, I know,
Speaker 1: people are you know again kind of the political whatever
Speaker 1: for you know, I want to be off Twitter and
Speaker 1: on Blue Sky as long as I can reach you
Speaker 1: and you're happy to get our stuff, you know, I'm
Speaker 1: happy to stay at either place so you know, or
Speaker 1: be of whatever place right, So as long as we
Speaker 1: can connect, I guess is what I care about. Yeah,
Speaker 1: definitely stay in touch there and until next time, folks
Speaker 1: max out
Speaker 2: M hm.