Maina Wycliffe is a Full-stack Software Engineer, Google Developer Expert, and Mentor who currently works at Flanksource. He is a Typescript Enthusiast and is the author of All things Typescript. He joins Chuck and Steve as he shares the reason behind starting his newsletter. His main goal is to teach developers to learn more about it and its typing system. 

Hey there and welcome back to another episode of JavaScript Jabber. This week on our panel we have Steve Edwards.

 

Howdy howdy from clear and cold Portland.

 

I'm Charles Max Wood from Top End Devs. There are a few things I just want to throw out real quick. One is you can go get a copy of my resume at topendevs.com slash resume. That's just a template you can use. It's a word and pages I think are the formats I have in there. So you can edit it yourself and put your own name and stuff on it. And then the other one that is, is we're starting a book club. We're going to be doing clean architecture with Uncle Bob Martin. That's going to start in December. And he's going to, I talked to him and he's going to show up to some of our calls. So if you want to come talk clean architecture with Uncle Bob, he won't be on all of them, but he'll be on some of them. So yeah, look forward to that. You can go sign up now. If you sign up now, I'm planning on planning out the next few books. And so you get to weigh in on that if you're in during the month, the rest of November and stuff. Anyway, we have a special guest this week and that is Wycliffe Mina. Do you want to introduce yourself? Let people know who you are and why you're famous. Yeah.

 

Yeah, sure. So, yeah, my name is Myna, WCREF or WCREF Myna. So you can say it either way. So I'm a software engineer at a company called FrankSource. I am a TypeScript enthusiast, so I really love hacking around TypeScript. And with that, I publish regularly or semi-regularly on my newsletter, all things TypeScript, whereby I get to cover different concepts My goal being to teach developers how to take advantage of the TypeScript system and in a better TypeScript code with less bugs. I'm also a Google Developer expert for Angular. And that's just about it about me. I'm not famous, by the way, but I will be at some point in the future, I guess.

 

There we go, saving up all those fame points.

 

Well, we always tell people that after this podcast comes out, then you'll be really famous.

 

I don't know if I want to be the kingmaker in the JavaScript world.

 

Um, that's right. So, um, yeah, let's, let's talk a little bit about TypeScript for a minute. And then we can talk about the newsletter. What, why TypeScript? Right. I mean, I hear people getting enthusiastic about react or, you know, things like that, but not, not necessarily TypeScript where it's like, wow, I could TypeScript.

 

Yeah, the thing is about me is that I can do, I'm a full stack developer by trade. So

 

Uh-huh.

 

my day revolves around working on the front end with either Angular or React on the back end via Node.js with TypeScript. And even sometimes TypeScript has gone to a lot of weird places, including

 

Mm-hmm.

 

infrastructure as code. can write to your infrastructure instead of using YAML, you can use TypeScript and then do everything you can do with TypeScript. And I was exploring all this, so I was doing all this. I realized a lot of people, including me then, didn't know how to write good TypeScript, didn't know how to write things in a TypeScript idiomatic way in

 

Mm-hmm.

 

a way that made it easier so that you don't end up with a lot of bugs. So about a year ago, I decided I'm going to go down into it. TypeScript and then I'm going to teach developers how to be better with TypeScript. So I started with a series called a byte of TypeScript a while back. I

 

Mm-hmm.

 

didn't do that for very much long, but after some time I decided, okay, I'm going to do a newsletter, all things TypeScript, that is about eight months ago. And I have been publishing regularly or trying to publish regularly since then and trying to teach developers how to take the TypeScript. by understanding the typing system. Because when you're coming from a JavaScript concept or JavaScript world, the typing system doesn't exist. And a lot of developers make a lot of mistake. And then when they get introduced to TypeScript, they're like, why do I have to care about types now? Why is that throwing that error? While in JavaScript doesn't, why not cast it or assert it as any and just get it done with? And I'm here to tell developers, do this, don't do that, that if it's not a hard turn. And that's been my goal for the last 8 months also.

 

Yeah, it's funny because we get on these and unfortunately AJ's not here. He's our resident contrarian to all things TypeScript. I think there are things that he likes about it, but for the most part, he likes JavaScript being lean and mean and a lot of the kind of built in typing that you get in JavaScript. Yeah, it's... how do I put it? It's not strongly typed, it's weakly typed. But,

 

Yeah.

 

you know, so your variables can, you know, you can go from one thing to the other and things like that. I do like kind of the constraints that it puts on functions and things like that as far as, you know, expect a string, right? And it'll actually, the tooling will warn me, dude, you said string,

 

Yeah.

 

right? So, you know, script tends to adopt a lot of the things that are going through the ECMA script process and adopts

 

Yeah.

 

those. I think that's where a lot of his... where a lot of his objections are with it, right? Because a lot of those features you can do in another way that is maybe a little bit more native to JavaScript, but sometimes some of the syntactic sugar and some of those features, to me at least make it more readable. Some of them I agree, I think they're completely superfluous to what you're trying to do in code. And unless you understand how that feature works and what it is, you're adding something that is gonna be mental overhead for somebody else to come and maintain. Overall, I tend to like aspects of it, but I'll also admit that when I'm writing JavaScript or writing scripting for code, I... I write JavaScript. I don't write TypeScript.

 

Hey, Chuck, real quick. Sorry, before you jump in, uh, Mina, I think it's safe

 

Yeah.

 

to say that AJ is a resident contrarian, not just resident contrarian on TypeScript. Uh,

 

Yeah, that's true, he has

 

Hehehe

his list. Hehehehe.

 

Right.

 

There are a number of things he's a contrarian on.

 

Yeah, he told me he wasn't able to make it. He said, this sucks because I'd be interested to see if this guy can answer more of my TypeScript questions. So you know he had some. But

 

Yeah.

 

I'll throw this out there real quick. There actually is a TC39 proposal out there on adding type annotations if you

 

Yum.

 

look on their GitHub repo. And I don't know if you were going to get to this or not. So I'll throw it in the show notes for anybody that's interested in looking at it. But it is something that they're looking of adding to JavaScript itself.

 

Yeah, you mean the one that was type says comment thingy?

 

It's an ECMAScript proposal type annotations. It's under the TC39 GitHub organization. So, and I've heard discussions about it before too. I'm not sure what phase it's in right now, but it's out there.

 

I think it'd be interesting just from the standpoint of, we've seen them adopt other stuff, right? So like promises came out in a library and then they adopted as part of the language, but they didn't adopt kind of the tried and true way that the library worked in every case. And I found that sort of interesting. And so I'm curious to see how similar it is to TypeScript and whether or not it would, you know, bring those aspects into JavaScript or not.

 

Yeah, it's always interesting to see how JavaScript is going to evolve being influenced by TypeScript in that I think we can agree we need some sort of like level and not a basic level or at least some level of type annotation in JavaScript. That would be great. It'll be nice if our types do not want not weak in that you could start with a string and end up with a date or an object by the time you are done On the other hand, it's always a question of when they were, if they were to stick on one way that's different from TypeScript, then what happens next in terms of does TypeScript adopt that or do they go their separate way and decide will converge on the tooling aspect of it?

 

Yeah, I will say that if they add this to the language, I think the one thing that makes me okay with it is that they are diligent about reverse compatibility, right, backwards compatibility.

 

Yeah.

 

And so the fact that I can go and I can write my JavaScript weekly typed, I mean, I have to say that the language I spend most of my time in is Ruby and it is also weekly typed. and it doesn't bother me that the variables can change types or that I can have a function or method return, you know, a myriad of types or anything like that. I like the tooling and I like what the tooling gives us, but yeah, at the end of the day, I wouldn't want to be constrained by it, right? I don't want it to be complaining that I don't have type annotations on it.

 

Yeah, yeah, I think that seems like it's a matter of creating a balance, trying to figure out how do you find that in between whereby

 

Mm-hmm.

 

if someone wants to be as explicit as possible, we can give them the necessary tools for that. While at the same time allowing someone who just wants to write a quick script or to do some quick prototyping to do it without having to be told, not to make that work.

 

Mm-hmm.

 

Yeah.

 

So I guess the next question is, what inspired you to start a newsletter about TypeScript?

 

Yeah, so I have been doing blogging for a while now. I think about four or five years now. And initially it used to be just about mostly Angular at

 

Mm-hmm.

 

some point, and we have done some Flutter Go and so on. And this time I wanted to do something completely different. So initially the idea ahead for all things TypeScript was like, what is the collection of articles? So card-created articles I would send out

 

Mm-hmm.

 

weekly every Monday. And I did that for a few months, whereby I would send like five to between five and 10 articles. I never had like a fixed number on it, but I would say not less than five and not more than 10 because I did not want it to be too huge. And then sort of like also included tweets at the end of it. And with time, this evolved to a point where I was like, now I'm getting subscribers when you get to 50. And I was like, to these subscribers who have joined my newsletter. And I was like, maybe let me start including lessons every week, not just curated articles. And that's how my newsletter evolved from just being something, an email list of articles you might be interested for to lead to something that sets out weekly lessons and sort of like a very small or very compact

 

Mm-hmm.

 

to elicit that discussion so that I can show 300 words and then I open it up for discussion for people to share their opinion on it.

 

Right.

 

So yeah, the first one is a huge deep dive which is over those 3 words. Yeah, so to answer your question, it evolved from at least a hard curated list to what it is now. And I'm quite sure that's going to change as we go, as I go into the future, as I try and decide where to place, where exactly I want all these types of things to be, because I can see sort of like having a challenge section at some point in the future and things like that. So I'm still evolving.

 

Alright.

 

What people want and I'm trying to figure out how exactly to teach TypeScript and be effective at it

 

That's cool, how many people do you have subscribed now?

 

I wrote a state of state of all things. I just sent it out about an hour ago. And that count was around 365 or more. I think there are two or more, three more subscribers on top of that. Yeah, but currently it starts at 360 something.

 

Very cool. So you send out

 

Yeah.

 

a set of links and a lesson every week. So it's two different emails.

 

I said I don't set out the set of links anymore. So the

 

Okay.

 

moment I set out two emails one is deep dive and the other one is sort of like a discussion topic with my thoughts my views on it and and then

 

Mm-hmm.

 

people can add their own content to it not that people have a few people which comment here and there but I'm still working towards getting my what is it called the uh tone of the email sites that I can listen to that. So it's forcing me to learn how to do articles that connect with people in a different ways because normally mine were usually blank or still in terms of like emotionless of the articles.

 

Mm-hmm.

 

And that never triggers people to share or discuss about that. So it's something I'm still learning.

 

Right?

 

Yeah.

 

I guess the other thing that I'm curious about is, are there, and I guess this is two questions, but I'm gonna ask it together anyway, are there topics that you find that people either don't get or. misunderstand or things about TypeScript. And the other question is, what topics do you find are the most popular when you put an email out, you know, gets more opens or whatever?

 

Yeah, yeah, there are some topics around TypeScript that people are always looking for information about. One of the most common one is generics. You can teach the generics 10 times and people are always like, what are those? But one of the more confusing one that is usually, I usually think it's funny because it's easy, but at the same time, people seems to be confused because when the answer you give them always forces them to do more. I think that's why people usually try to not understand it is how do you convert your types. When you get data from the API, the TypeScript doesn't know what type it is. How do you tell TypeScript what that is? So in a lot of ways, a lot of people usually go to assertions. And if you know what you're doing, they are great. But if you're not careful, you might end up in a situation whereby you are working on the long model of data because you are starting auto TypeScript, this is something different. And this is why I usually try to explain to people how to do TypeMarlin. I remember a while back we had an argument in an interview which I was being interviewed on how exactly to go about it. And the interviewer was Adam, and the only way to do it was assertions.

 

Mm-hmm.

 

And I had to try and explain them. Yeah, assertions is one way, but I don't recommend doing that. do a LLP.

 

Right.

 

Yeah, so in terms of popularity, I would say, to be honest, I'm not sure which are the most popular ones, but time-nulling would probably be at the top of my list, thereby directly connected to assertion, but in this case is if you have something with multiple types that is unions, how do you get the type exactly you want? Or how do you come from a broader type to a more null type that you can then consume safely? So

 

Right.

 

I shall find those topics capture people's imagination. And then the other concepts around any unknown, never, how to use those different concepts, those different types in TypeScript properly within your application.

 

Alright.

 

Yeah.

 

So Steve, have you done much with TypeScript?

 

No, that's been one of those things where I've read a lot about and listened to endless discussions about TypeScript, but haven't delved in it too much. We have been implementing it more and more in our large app that I do on a day-to-day basis, but I haven't had too much opportunity to write it yet, to use it yet. I know in, you know, view two, it was sort of a bolt on, it was sort of a pain in the rear to try to to implement TypeScript with downloading extra libraries and stuff. And I know in Vue 3, it's implemented out of the box, so you can do it much easier. But I understand the use case for it and how ideally it prevents errors. And because I've certain errors that I've run into before, where you're passing a string something and it's looking for an object or some of the basic stuff, on experience using just yet. I'm sure at some point I'm gonna have to really dive into it.

 

Yeah, I mean, that's what I'm seeing as far as uptick and adoption, right? I mean, Angular 2, I think they were pushing, they had an at script that they were putting together on their own. And then they, I think they had conversations with the TypeScript team at Microsoft and they said, this is filling all the needs we were trying to fill with the other thing. And so they adopted it. And so you see a lot of adoption of TypeScript in Angular and you have for the last few years. And at the same time, React was doing ES6 for a long time, and I'm seeing them move in masses to TypeScript. Because again, they're getting a lot of what they want from TypeScript, and the React team is encouraging people to move that way. And then, yeah, with Vue 3, it seems like it's encouraged, but I might be misreading that.

 

Well, yeah, I think it's encouraged. It's not required.

 

Right.

 

Uh, and view three itself, the core language is written with TypeScript. So that helps, you know, in a lot of your, uh, when you're using your IDE in terms of type hints and that kind of stuff. Uh,

 

Yeah.

 

but you can do, you can do view without it, but it's just a lot easier to use it if you do want to use it.

 

Yeah, well you can do Angular without TypeScript too, but it's really painful.

 

Yeah,

 

Yeah.

 

I'd heard that it was pretty much a requirement with Angular wherever

 

It basically

 

they're up to.

 

is. I mean, if you wanna bang

 

You...

 

your head against a wall, you can make it work. I've talked to a few people who have, but yeah.

 

And

 

Yeah.

 

they have very flat heads too, right?

 

They do. They've got scars

 

Yeah.

 

on their foreheads.

 

Yeah,

 

from where

 

we

 

the

 

think

 

wall

 

you

 

bit

 

have

 

them,

 

to go

 

yeah.

 

out of your way

 

Yeah.

 

to not use tape script.

 

Yeah, you're asking for a world of pain in Angular, because

 

Yeah.

 

everything just expects it to be there.

 

Yeah,

 

But yeah.

 

I can't even imagine from this position where I would start if you told me to use JavaScript with TypeScript.

 

Yeah, I talk to some people

 

Thanks for watching!

 

who stubbornly put in hours and hours and hours and hours to try and make it work.

 

Uh-huh.

 

Yeah.

 

Why just because they hate TypeScript and don't want to learn it or why? What's the point of trying to avoid it?

 

It was either that or they just wanted to prove that you could do it the other way. And I don't think they won that argument, even if it worked.

 

That sounds like something AJ would do.

 

So

 

Hahaha

 

anyway, but yeah, so. I see a lot of things going toward TypeScript. I mean, what have you done with TypeScript? Mina.

 

Yeah. Like I said at the beginning, one of the more interesting was infrastructure as code.

 

Mm-hmm.

 

This is mostly enabled by AWS. A few years back, they released AWS CDK component, not cloud development kit, if I'm not

 

Mm-hmm.

 

mistaken.

 

OK.

 

And this allows you to write your infrastructure code. That is that provision

 

Mm-hmm.

 

infrastructure, and so on using TypeScript and then use their CLI to build that into cloud formation and deploy. So this allows you to use just for testing normal TypeScript code and everything is TypeScript. So one thing I should say at my previous company, because that's when we used to use TypeScript a lot on everything is that all our stack from the back-end front-end infrastructure is code was all in TypeScript. So you had, you didn't try it in any other language. maybe apart from YAML, I don't know if YAML can be called a language. Everything else

 

Uhhh...

 

was in TypeScript.

 

Yeah.

 

That was the more interesting things to do with TypeScript, but other than that, there is also the issue of front-end work. So, half-work takes sense with both Angular and TypeScript, not TypeScript, but React. And then on the back-end Node.js, we used to deploy everything on What the record we used to deploy everything on? Lambdas

 

Heroku?

 

AWS

 

Oh,

 

and us

 

Lambdas.

 

so yeah, so

 

Okay.

 

you are everything no need for a framework So everything goes just as you go find your that does everything so no no framework at all so currently at work Mostly work as a front-end engineer mostly types react typescript We have a mixed code base, which is basically JavaScript that is where to start it out to migrate and push it towards TypeScript. I think at the moment, the last time I checked, we have like 60% of it in TypeScript. And it's still a challenging because we are trying to do an MVP here.

 

Mm-hmm.

 

So TypeScript is not a priority. So

 

Right.

 

I seem to be the only one to be taken seriously. And it seems like we have to do a lot of work afterwards and we have a product and we need to now say, let's like maintainable code and let's clean up all the, any types allowed because you should come across any, cause close a lot. And you have, we have, so we had that discussion and we are like, yeah, if you come across something you can fix real quickly, do that. Otherwise, just leave it. If it's working, don't break it or don't fix

 

Right.

 

it. Afterwards, we'll try and do the cleanup once the MVPS is out.

 

Makes sense. It's interesting too to have the conversation about making the transition, right? Because, you know, like Steve said, right? A lot of stuff is view

 

Yeah.

 

to JavaScript and you're moving to TypeScript. Steve, you said your company has been making that transition too. I'd love to hear what both of your perspectives are as far as adopting it into a project that wasn't originally started in TypeScript.

 

I don't know how much I can add to that in regards to ours, because it was started before I came on board.

 

Mm-hmm.

 

The app originally started to be built 10 years ago. And so a lot happened since then. I know that my boss has told me that he tries to implement TypeScript in wherever possible. In the case of our applications, it's view single file components as it in other JavaScript files that we'll implement, whether it's Vuex or just some other helper functions or mix-ins or stuff like that. So it takes a little bit of learning, especially with the complexity of some of our app and some of the TypeScript implementations. But it's not like, okay, we will do this and have to do this every time. It's more of, okay, whenever we get a chance, to implement it and update it.

 

Right.

 

Yeah,

 

How about you, minor?

 

yeah, I think this is the code time I'm doing this. I don't really know why you should end up with code bases that start out in the JavaScript that I did to a TypeScript, but it seems like I have an affinity for them. But the general consensus I have come across is that don't try and sit down and say, we are going to migrate this all the way to the end. Try to take small chance if you find yourself working on something that hasn't been migrated do the migration. So at the current tree, we have a policy of about, don't spend more than 20% of your time trying to do the migration. So try to make a sensible decision on how long it's going to take because you don't really want to be spending too much time to do that. On the other hand, it's good to leave, if you can't do a complete migration of a file, I'll probably say don't migrate it, it in JavaScript for the time being instead of having like incorrect types for a file because that gives you a false impression that that's migrated and you might prevent someone from having a look at it a little bit later. So the biggest challenge I have seen is that especially if you are new to a code base is trying to make to figure out how exactly to type things without or the intention of what the code does. So you find yourself trying to figure out is this correct or not correct? And the worst part of it is that because TypeScript doesn't exist at runtime, you probably never going to know until someone else comes along and say, oh no, this is wrong, or someone to implement integrates it in the wrong way. So those are the kind of challenges around migrations have come across. So the other one is obviously If you do it wrong, you'll find yourself relying with either any of those TS directives for ignore LLXL except expected are left and right. And I'm not a huge fan of those. I don't think I have anything to add to that.

 

Yeah, I was just trying to think where we want to go from here. I mean, do you have other plans at this point for the newsletter?

 

Yeah.

 

Are there other things you're looking to add to it or do different on it?

 

The only thing I was thinking of Explaining a little bit more is to do with my creations because I feel like we do cover a lot All there is a lot of literature out there a lot of content out there that covers doing things in typescript But we don't have a lot of content out there telling you when you're moving from JavaScript to typescript This is how you do it when you find yourself in this situation These are possible ways out of it or planning out a migration, try these strategies. The reason

 

Hmm.

 

for this is because we have a lot of code that exists in JavaScript. And if people just say, today we are going to do migrate using TypeScript left and right and without a strategy, the issue ends up to being a very painful process for them. So the next few weeks, I'm going to try and cover those and use my experiences in my current company that I worked for to try and bring some of those things to people's mind so that they can do migrations in a better way or in a more smoother way. Otherwise you might end up developing your own tools to do the migration. I think Stripe did that. I don't really know how well that went for them. Because any other attempts have always been a burden for automatically from JavaScript to JavaScript.

 

Very cool. Yeah, I've done a few migrations, not of JavaScript to TypeScript, but of other systems. And yeah, what you wind up doing in a lot of cases is basically what you said. You sit down, you make your plan. I mean, anything new, you know, that doesn't require, you know, the kinds of infrastructure that make it hard to write TypeScript or write whatever the new system is. do those in the new language

 

Yeah.

 

or framework or whatever. Then, yeah, maybe there's some infrastructure that you just simply need to update. So you go and you work through those because now it's painful to have them in JavaScript. Usually what we did is we had some kind of documentation, so it was Notion or something, and we'd go in and we'd say, this needs to change. This needs to change. And what you usually wind up with is you wind up getting about 70% is my experience of your app will kind of naturally flow to the new system, right? And some of it will be painful

 

Yeah.

 

for you to change because it works great the way it's written, but, you know, eventually there's enough tech debt around adapting to it that you just you have to update. It's more it's more work to maintain how it is at this point. Then you've got the other 30% that's just stuff that just doesn't change or doesn't get often used. What I found there is that oftentimes what we wound up doing is having the conversation about whether or not we even needed it as opposed to whether or not we were going to convert it.

 

Yeah, it's a the 70% is an interesting number if you think about it because it's unless you put your head into it and say it needs to be 100%, you always get to the point where you are like very happy with your code base because no one touches the other stuff, so no one is going to migrate it and no one is suffering from like having to edit but for because you have already migrated everything by you have to touch every day where most of the changes are those solutions are usually the first ones to be like, and let's get those on to test, let's get those. Even for those companies that are coming from, we don't write tests, we need to do some tests with test coverage. It usually goes into that direction whereby anything that's regularly touched is the one that gets affected first, and then everything else slowly, and then it gets to a point whereby it comes to a halt in stuff whereby even people are afraid to touch those stuffs no one touches because it works, So everything comes in and we are and all I just like like that and maybe at some point you can have that bit about Removing them if you don't need them or something Yeah.

 

Cool. Well, are there other things you want to make sure people know about either TypeScript or the newsletter?

 

Um, not in terms of TypeScript. So the one thing I have been trying to do literally in terms of TypeScript is that I'm trying to sensitize people to understand, to have a good understanding of JavaScript as well and understand that the relationship between the two. Because once you write your code in TypeScript, it's going to run in JavaScript. And if you can understand how it's going to behave at runtime, then you're going to write your code a little bit better and know what to expect. And also understanding the typing system for both of them because TypeScript is statically typed while JavaScript is weakly dynamically typed. And that allows you to know, still, if you don't do your validations at runtime, you might end up doing, having bugs that aren't explained. So one of the things I'm trying sort of like move people towards the direction is sort of like validate your data at runtime. So you don't just say data that came from an API or near the external sources, just a certain it, but you can use something like IOTS or Zord to do the validation and ensure that you have better, you're working with the correct data at runtime, which makes your program much more typesafe.

 

Cool. Steve, did you have any other questions or thoughts that you wanted to share?

 

No, not at this point. Like I said, this is a discussion that's happened all over the place in terms of TypeScript.

 

Yeah.

 

And I guess I'm at the point where I'm a believer, but I haven't believed enough to really implement it. Although I will say I am starting a new app project outside of work. I guess you'd call it a side project where I'm going to, it's going to use inertia.js with Laravel and Vue 3. thinking about, I might try implementing TypeScript there. So we'll see how that goes. Knock on wood.

 

cool. One last question that I have for you, Mayena, is a lot of people are, you know, they're kind of in the boat that Steve has described or that I've described, right? I haven't gone deep on it. I'm curious about it. I think it's probably going to make some of the things in my life easier when I'm writing code. Do you have some favorite resources get into this or trying to understand it. Um, and then I'm not just talking about like intro tutorials, but you know, places where they can go throughout their journey, whether they're experts or not and kind of know what's going on in the TypeScript world and pick up new pieces, ideas and things that they can go work off of.

 

Yeah, yeah, they are... I'll probably start with my newsletter. Obviously, but...

 

It's the

 

Oh,

 

best.

 

top?

 

Actually it is. I went and looked at it because when we had you on adventures in Angular, I went and looked at it and I was like, this is really well put together and the links are solid. So yeah.

 

Thanks so on top of that is there are few people on Twitter, I don't know if I Remember the number I should put a put a list on The show notes are so I'll post the comment with that one of them one of those that couple jumps it might is I think a Matt Peacock He if you want to learn typescript all day from start to the advanced he does these short videos He has courses. Yes almost everything about TypeScript. And the other one is the author of learning TypeScript, the book. I think I shared that on the show notes from last time. What is his name? I'm terrible with names, so just forgive me. Forgive that. I'm going to put those on the show notes. And he basically does a lot of TypeScript. He's also one of the maintainers ESLint for TypeScript. So those are the ones that jump into mind in terms of TypeScript resources. And then in terms of books, they start is running TypeScript book, but then there is also another book by forgetting the title for that last book, which is another one. Is it a book with more like 50 lessons in TypeScript? sort of like things to do in TypeScript whenever you find yourself in this situation. It's a very nice book that alleges the lessons from beginner all the way to an expert. You are always going to find something interesting from migrations to understanding internal working of TypeScript to understanding how to do various concept with TypeScript. It's somewhat in my shelf. Let me just see if I can grab it real quick. Just a sec.

 

Yeah.

 

So that one is effective type screen.

 

Awesome.

 

Yeah, so very nice book. And by Dan, I probably going to butcher that name last day. And then this one is by Josh Goldberg, he's on Twitter and the book is turning typescript. So both books are nice for both beginners and experts and they have sort of like different approaches with effective types of having like lessons in this situation, do this and then having sort of like a code that you can follow. Or else the other one is more about how to do different things in TypeScript with all kinds of that. So

 

Yeah.

 

that one plus, Matt Peacock, he has courses which are free and things like that. I think something to do, something called Total TypeScript is a course he does, which has things from beginner or there to types and do crazy stuff. He does those short less than two minutes videos on Twitter and they always like uh leaving you to in a moment where by your like oh I didn't know I could do that in TypeScript

 

Very cool. Well, thanks for all those. We'll make sure they all wind up in the show notes. I'm going to push us into PIX, which is our next segment of the show. And you are on Adventures in Angular, so you understand PIX. Let's have Steve start us out. We need a high point, Steve, a high point.

 

The high point of every episode, the dad jokes of the week. That's right. Oh, let's see here. So the other day I went to the, you know, I was at one of the stores and big stores and you know, they always have, well, let's just say I had the nastiest, rudest, slowest cashier of the entire day, but I guess it was my own fault for using the self-service checkout. Right?

 

to see that.

 

Yeah, yes. So why did the lion eat the tightrope walker? He wanted a well-balanced meal. And finally, did you hear about the guy with the irrational fear of buffets? He just couldn't help himself. Thank you.

 

Alright.

 

Chuck is so conditioned that he doesn't even smile anymore.

 

Oh, sorry. Anyway, I'm gonna jump in with some picks. I've been doing the game board board game picks. Last night, my wife and I went over to a friend's house and we were playing games with two other couples who were really good friends of ours. And we played a game and I always mess the name of the game up. So let me make sure that I'm getting it right here. It's betrayal in the house. on the hill. Betrayal at House on the Hill. Yeah, that's why, because anyway, I guess House on the Hill would be proper now because it's a play, I don't know. Anyway, came out in 2004. There are a couple of expansions to it. We were playing one of the expansions, but this is a friend, a game that my friends had. And... Anyway, what it is is it's kind of like, so you play teenagers who go into this haunted house, and they start exploring the house, and eventually they trigger some haunted activity. When they trigger the haunted activity, then typically one person winds up being the betrayer. That's why it's a betrayal. You're the traitor. In this game, I was the traitor. It picks a random scenario out of the scenario books. If you're the trader, you're playing monsters and you're doing other things to try and meet your win condition. Then the players become heroes and they're trying to essentially escape. So they have to meet certain conditions to be able to escape the house. We had a good time. We went over there at like 8 and we played until like midnight. And it was awesome. It says that the average playing time is about 60 minutes. We did wind up with a haunt from the expansion. And just the structure of it. The different haunts take different amounts of time. Yeah, it typically runs an hour, maybe an hour and a half. But this one, for whatever reason, just took a really, really long time. And it was complicated. of time to figure stuff out. So anyway, it was a lot of fun. If this is one game, like we get into kind of the involved board games and card games, and like one or two of my kids are really playing with us and the others won't, this is one game that all of my kids will play. Because they can just go keep exploring the house, or they can go and try and fight the monsters or they can go and, you know, and you're rolling dice. You know, but it's relatively simple compared to like D and D. So. Anyway, at the end of the day, that's kind of where things shook out and it was, it was a lot of fun. Um, so I'm going to pick betrayal at house on the hill. Um, I got it right. I won't do it again, but I got it right that time. So anyway, I'm going to pick that.

 

Hahaha!

 

A few other things I did mention the book club, we're doing Clean Architecture, go check it out, topendevs.com slash book club. I think I'm gonna make it book club and book dash club and they'll just, one of them will forward to the other one so you don't have to think about it. And then finally, and this is the thing, and I'm really starting to get it all come together. So initially what I wanted to do with top end devs is I wanted to have just a bunch of courses, right? And so you would subscribe watch any of the courses that are available. I'm still doing that, but it's not my primary focus anymore. And so I'm looking for authors, and you'll get compensated if you author a course for us, right, and people go watch it. But we're making the courses so that people can buy them one off or they can subscribe and watch a course, or watch any of the courses that are available under the membership, right? But the thing is, is I joined a group that was doing things a little bit differently, and what they were doing is they have weekly calls. They have two weekly calls. They all have different themes to the calls. And so people can show up and we just discuss a topic. And sometimes we have experts show up and help us with the topic, right? So what I'm looking at is I'm looking at doing the same thing, right? And so like two or three of the calls every month are gonna be Q&A calls where you just hop on, you ask the group, I'll be on there, right? So you can bring questions you know I can answer, and we'll just talk through things and make sure that you get the help you need, right? We'll have other ones where there are more get to know you calls, but I also want to bring some in that are more sort of career focused. So we're talking like my company offers a 401k, how do I best take advantage of it? Or my company offers a stock purchase program, how do I take advantage of it? Or you know, how do I deal with being the team lead, right? And have a leadership session month. And then I'm also looking at having extra sessions that are the ones for each show. So one will be JavaScript, one will be Ruby, one will be Angular, one will be React, one will be Vue, and we'll do all these calls too. But yeah, so I'm also looking at the technical topics like say DevOps or infrastructure, right? You mentioned infrastructure as code and doing TypeScript to do infrastructure as code. So maybe we bring somebody in who knows all about hour an hour, walking us through how it works and answering questions about it. And so I do want to have those kinds of technical things too. And some of them are going to be more broadly general, like how do I get started in doing security for my app, right? And some of them will be pretty specific about here's how you set up serverless so it'll run on GCP, right? So it'll be a good mix. JavaScript on GCP, right? Then that may show up in the JavaScript Meetup instead of a regular twice a week Meetup. At this point, I'm looking at running them all on Zoom. And then afterward, I've been playing with a system that I really like called Gather Town. And so after the Meetup, what I'll do is I'll open up Gather Town. And so everybody can log in there. And effectively you can walk around the little world that's in there. group, then you can participate in their conversation. And so then I'm assuming like three, five, ten people are all interested in discussing something further there or there's another group that's discussing hiring, right? Because we're seeing a bunch of people get laid off these days. It's just like, how the flip do I get another job? Or who's hiring? Or things like that, right? And so we can kind of set out areas where people can go talk about the different things. Or if you just want to meet people, right? join the conversation and just yak about whatever, right? So that's the idea. That's what we're putting together. And then yeah, you'll get access to the courses. So like the, I have a resume course that'll be part of the deal. And I want to start adding more technical content that you can just consume that are just videos, like 10 minute videos. So that's what we're putting together. And so if you're looking for a community where can have, be part of the conversation. And the book club's also included in that, um, you know, and learn stuff and be staying on top of things, you know, and knowing what's, what stay current on in whatever area you want to be in. Then, then this is what we're putting together. This is what we're doing for that. And, uh, yeah, I just want it to be a place where people can come and. Yeah. Just be part of the conversation and have, have a good time. And this is, this is something I always wanted for. my growth journey is just people to connect to who loved it as much as I did. So anyway, you can go to topendevs.com slash sign up and you can join. And then there was something else I was gonna pick. So I just finished the book Never Seen. I think I picked this book series on previous episodes. The first book is Keeper of the Lost Cities and is kind of a Percy Jackson, Harry style where you have a bunch of kids, you know, going and fighting for good and, you know, there's magic and stuff. And they're all kind of... So I've read fantasy books where there are like definite rules to the magic. And then I read fantasy books like Harry Potter and Percy Jackson that don't have definite rules, right? They can just do things and then they can do things up to whatever their limitations are. And that's more the magic style in this book. And they're fun. My kids really love them. And they're interesting enough for me to keep listening to them. I've been enjoying them, right? It's a nice way to just kick back and chill. So anyway, lots of picks. Sorry for rambling. Myna, what are your picks?

 

Yeah, no, I just have one. One

 

All

 

of the few,

 

good.

 

and then I got at least 100 of them. I'll start with a movie, something I'm looking forward to seeing. No, actually not a movie, a TV show. I don't know if you have seen or watched Dragon Prince on Netflix. I saw The Fourth Season is Out about these two kingdoms where one is human-red magical creatures and they are at war with each other and then they go and steal the dragon prince is now an egg when they stole them and then the prince in the human kingdom wants to return the egg against the wishes of some people within the kingdom so his father is killed and the person becomes the legion is after them because they don't want the egg returned to the other kingdom which is called Zedya. And it's an interesting journey around how the young kid who is very young and his brother walk towards together with people who they were told they were enemies to unite everyone else. And in the end, the dragon prince mother who was sick wakes up to see her son and everyone out there, that is humans and other magical creatures in front of them and is very, very happy. So I'm looking forward to watching the fourth season. I haven't watched, or very so up to the point where I narrated very poorly. That was up to, I think, that season. And it's something I'm looking forward to watch. It's a very nice sort of like adventure animation. And I'm sort of into huge animations. So the other thing I really wanted to mention around, who are starting out their journey, even experienced one. But most one is that Google has this DevFest season, whereby we have hundreds of events happening in different cities every weekend. So if you are looking to connect with developers within your regions or even outside your region, because some make as far as the house as a smile, please look up for those events they have. It's called gdg.community.dev. I think that's the website. And you can find events all near you. And I can promise you this. There is an event near you. And there, you're going to be interacting with other developers like yourself. You're going to be meeting experienced developers. You might meet a few Google-assigned there, and also a few GDEs. a very good network and be able to learn from some of the best people and be able to sort of like have answers from people you want and this is all in person if you want but there are some of those which are a virtue but at the end of the day when you're making the connection and talking to people that's when you are able to understand what you need to do for your career and move to the next steps. kwa mpia.

 

Awesome, if people want to connect with you online, where do they find you?

 

So I'm currently on Twitter so My cliff at a Scott dev Everyone everywhere else says that is LinkedIn github minor weekly Double FF. Yeah, so minor weekly no spaces in between Apparently someone is using my now we click on Twitter. They have no idea who I didn't know there are two minor a minor

 

Right?

 

No, I'm not talking about that one.

 

All right. Yeah. Well, and how do they sign up for the newsletter?

 

So all things TypeSquad.dev, you'll be able to access all the issues there. And then there should be a sign up. You'll add on to a sign up page where you'll be asked for your email address. You just get the contact from the newsletter. It doesn't come from any other place. So your list is there. I keep that email list as secret as you to just send you the emails from the newsletter.

 

All right, cool. Well, we're gonna go ahead and wrap it up here. Thanks for coming. And until next

 

Hmm

 

time, folks, Max out.

 

Adios.

 

Thank you, bye.