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