Video Feed
DDD | Web3 & Angular | Developing Components | WOW SEO

0
Angular
01.22.2021

English

Manfred Steyer, Zoe Augustinos, Peter Smith & Jeff Whelpley

Powered by ng-conf: www.ng-conf.org
Up At Night Ep. 001 | Manfred Steyer: DDD | Zoe Augustinos: Web3 & Angular | Peter Smith: Developing Components | Jeff Whelpley: WOW SEO
presented by the team at Upstate Interactive: upstateinteractive.io
@upstateagency @ManfredSteyer @jeffwhelpley

Transcript

Everybody joining tonight. We have a that you're talking about DVD as well. We have Jeff Buckley on a segment we call Wow Steve. This is a show where we talk about angular all night. And in between, we have segments on the best angular speakers in the world. So grab a coffee. This is upstate interactive at night. Hey, everyone, this is up that night we are doing the newest bestest show hosted by Angie Khan. So I am Peter Smith with Zoey Augoustinos and we're two of four partners at a software consultancy called Upstate Interactive. We do fastback JavaScript applications using ANGULAR pretty regularly, and we also work with smart contracts on the anthurium block chain. It's a fun little company to be a part of for sure. When this show came about, it was as a result of something called up at night being a title for an after hours, and we would always done Zoome with everybody at the company. We did a number of them with no tactical and we did some others that were purely social chatting about a movie that we would all watch. And now we're here. And what we'll be doing is having a conversation, not all that on like anybody else might be having after their work hours with their employees or with their colleagues and with their friends and collaborators. And it certainly doesn't have to be at night. But I say I relate to it because I'm managing a company. There's a lot of meetings. There's a lot of things to keep track of. And oftentimes, if I want to continue learning, gaining new technical skills or just work on something creative, it's in the evening and it'll be exciting for us to share some of those projects with you. Yeah, I think everybody's going to go to like it. And certainly I would like them to say that they do want to know what is it that the the skills that you're working on are what's up with you? Yeah. I mean, over the last few years, been working with Angular, started working with native script a couple of years ago using Angular to build native mobile applications. And now the latest transition has been into Web three because we have smart contract developers on our team building on the Ethereum block chain and we want to bridge that gap with our Web development team and and learn how to interact with with those smart contracts and build out great user interfaces for them. So I'm starting to get into that and learn what what three is all about, particularly with the angular. Well, there's a couple there in there. There's not only a web through before that, the the native script. It's another way to use angular in a way that it's other than what folks tend to do with client side stuff as a majority. The native script being, of course, deployed on the IOC or any other platform that's basically just not Web. So I know it includes desktop and some others, but then Web three, that's a whole new topic all on its own. I know that it's something that we've got a segment for. So let's go into our first segment that's called Zoey and Webb three. And I know that about the project. It's something that the upstate interactive team worked on for our client. It's called You Donate. And in this we'll see Zoey talking and showing us through how to connect Webb three, which is meant to connect to a browser, to a smart contract using angular. I'm going to show you how you can use the Web three JFK Library in your angular application to interact with an Ethereum smart contract, my colleagues are solidity developers, so I'll be interacting with a couple of functions on a contract that they wrote called You Donate. We're going to use the smart contract to create an organization that people can donate to for our cause. And then we're going to retrieve another organization that we want to donate to. The first step is to install Web 3GS and connect to your wallet account. Web three, J.S. is a collection of libraries which allow you to interact with a local or remote, ethereal node using an HTP or IPSI connection it here on GitHub, you can see it's an NPM install into your angular app. We're also going to need a wallet account. I'm using metal mask. It's already downloaded and I've added a Google Chrome extension and logged in. We're going to be using the Rob Stein Test Network for our interactions. Now that you have that set up, we have to create a service in your in your angular application, mine's called Contract Service and I've imported Webb three in order to connect to your wallet account. We're going to be using another library called Webb three Motal. This allows developers to add support from multiple providers in their apps. It's written in react, so I had to adapt it to my angular service a little bit. You can see the Web three model is set up, it includes some provider options and we have it, um, included into our connector account function, so. We are going to call the connect function and then select a provider which will be using my name ask, and then that will call Web three G.S. function in order to get your account and restoring our account address or application. So let's do that and I am going to connect account. This is calling the Web through mobile and then we're going to select our provider of mask and it's connected. As you can see successfully now, we want to create an organization using a function from our smart contract, so we need to add an ABI JS file into our app. And Abi, Dodgiest file. Is essentially, Jason, that includes all the functions available on your contract, we have to explore are you donate your address and are you donate Abai and then we're going to import that into our contract service so you can see that the you donate address and the you donate, Abbi, is imported and we're going to be using that when we make our function calls. So in order to create an organization, I have a form. That is going to pass in a wallet address, which is a unique address for our organization so people can donate to it a name and a token address which will just specify whether we're using ether die and we're going to be hard coding in an I.D. because this function requires a unique I.D. which needs to be created from our application, which is a little unusual. So in the future, we might need to create a traditional end to create our IDs for us. So I'm going to be passing in 10 to 10. And then that's going to be passed into our container where we're going to be. We're going to we are going to be calling our contract service. And then our contract service is going to. Call our FBI file or contract, and then we're going to use the organization method on our contract passing and all the parameters and then using the standard method. Which uses our account that we're logged in with. And I'm creating an observable that then I can set onto our New York state. So let's try that. Create an organization called Zoey Don't Eat with a unique address. And a token address that specifies we're using eath. And submit it. So looks like it's going to be OK to confirm it's just going to require a small gas fee. So the contract is interacting and we're going to just wait a moment to see if it works successfully and if the organization gets added to our state. Looks like we have success before we take a look at the state. I just want to show that you can get more details about your interaction and then activity. And you can also take a look here as well. So we take a look at what occurred here, we can see we have a lot of information added, which looks correct. So now if we want to get an organization back, we can either call our organization or we can call another one, let's call another organization, but I'm just going to show the process here. So we have another form where we're passing in an I.D. and and then that's going to be passed up to our container component, which is going to dispatch an action to get the organization. And we're using, in effect here to call our contract service. Once that once that goes through, we are similarly using Web three just to pass in our Abai and our address from our contract. And then we're using the get organization method on our smart contract passing in the parameters. And then instead of making a stand call, instead of using the sun method, we're using the call method and still passing in our account. And then we are making a small adjustment using Web 3GS get balanced method to add the balance of our account of our of that organization to what is returned in the observable that gets added to our state. So let's let's take a look at Organization 10, it's a much faster to get an existing organization than to create one. So this organization, you can see the PayPal wallet address and a balance that's included here. So we can also take a quick look at the interaction. Um, more if we'd like, but in the future, I want to make another call to donate to an organization and and show what else is possible with some of the some of the functions on this contract. Oh, thanks for watching. And hopefully we'll see you the next one. All right. Now we're back. And I just want to follow up on that segment about Web three, and it is using the You Donate contract, which wasn't obvious in the in the segment. But I just want to follow up on why Web developers should care about what Aboutaleb three and start learning about it. Well, what we're currently used to using as what's referred to as Web 2.0. It was initially a front on revolution, making it possible for users to create their own content. It's made it possible for applications, social media applications and the ability to search and do more than just read on the web. But everything has been centralized and you don't have to stand and understand that it's your what your data is doing and have an ownership of it. So Web three is more of a back on revolution, its protocols on the block chain to decentralize data and make the Internet more fair and give users more control of their data. There isn't really, you know, something that, uh, replaces user interfaces. We're still going to have to build. We're still going to have to build that out and learn how to interact with these protocols on the block chain. So front developers are going to have to learn how to interact with smart contracts, just like will we interact with them on with APIs. I wonder whether it'll become invisible. Basically, it's clear that there is a chrome extension necessary. Is it something that's going to always be like that is hard to answer and say that it will be. It is something that, you know, the future is not set in stone, but there is a lot of utility that the smart contract style development brings to the world. There are certain things that you can't do without it. And so it's got a place and it's likely to continue to find it for us as developers. It's always about how do you get yourself into a new technology without having to relearn everything that you've ever learned before. So when I hear about Web theory and then it relates to a theory I'm having, not really done it myself, I'd like to figure there are things that you took with you from what you've already done in order to be able to do what you're currently working on there. But there are certain things that carry over. Absolutely. I mean, the contract itself, as you saw in the segment, includes the Jason functions that we can interact with from an angular app in a service. It to me, working with APIs, it feels a lot like a post. And I get although learning about not being able to talk to smart contract developers, understand the differences is something that I want to continue to learn and and how they're still going to be a need for attritional back. And there's there's differences there where you're not going to want to do a get request for a ton of data all at once. But you are going to want to retrieve data that has, you know, audit trail and just more specific things you can't do with the traditional back. And so I think there's a lot that Web developers can apply to as they learn how to interact with smart contracts. Well, that's great. I know that there is more to come about that. And for a long time to come, there's going to be discussion about what it means to be able to give a experience to folks that don't know what lockshin is, don't know what the technology is. I think if I think about it in relation to what I mostly know about, which is databases for sure, folks that are not in the world of software engineering are clueless that there is something called postgrads and do something on my school. They're not meant to be known about either. They just exist for developers to build things that ultimately can provide something nice for everyday folks. So at the moment, a theory and being one of them, it seems like. It's been put out there as if everybody's got to know about it or you're you're not going to be able to participate in the future economy or the future of development. Basically, I think it's like maybe it's not something everybody needs to know about, and it's just that when you do need to build something, then it's there as an available tool, just like anything else that you might. So there's other things going on in the world. One of them, I think, is ever on my mind is that there is bootcamps and I know that they're not new, but I guess they've got to be going through a transformation at the moment from things that are mostly in person to things that are mostly online. Every college on the continental U.S. anyways, has got challenges around it. And I mean, you get yourself a boot camp degree, I'd say, based on where our that folks got those degrees having come from other careers. Is there anything about coming from a non computer science background that is maybe a better fit, though, than we've seen? I put my head on. I bet I can come up with something. Yeah. I mean, we we work with a lot of developers that have come out of bootcamps. I mean, I went through one myself without having a traditional computer science background. A lot of our team members had different careers beforehand, like in finance or I.T. And there's it's nice to have different perspectives come to the table. But I think the biggest thing is just the hands on learning and the amount of passion that our our team has by, like not being in the tech world and then learning this new world and wanting to continue to gain these skills. And but there's there's so many resources online now that the model has to change. People can continue to learn software deployment skills at their own pace. A lot of different resources available. But I really think the hands on learning through projects and through mentorship, through boot camps has been something that's allowed it to be successful. Yeah, you find that people go far when they've got a mentor, whether it's an actual person who's just got a, I don't know, a 30 minute window a day to answer what's going on to your your questions that everybody has had. It's just night and day nicer than being it to start a computer. I definitely think that that's all right. So let's jump in another segment now and let's talk about how we got to here. So as I took a vacation at the very beginning of that, I started to watch an energy convoy videos and I came on some ideas from Montreal. Steier Manfred's been talking in the angular world for for a bit. And most recently, he's been really advocating for domain driven design. And what's happening with that is you're architecting an application and you also wrote an ebook on it. And by looking at the e-book and reading that and whatever else that is put together from angular architecture, I realize this is pretty cool and shot him. And, you know, and after talking to him about it, there are some gaps that I had that apparently other folks have as well. So in this segment, and it's known as montreat in a few minutes, Manfred in a few minutes talks about something that he's given some length to publicly, that he's gotten a number of questions about. And this one's on that topic of DDD. So let's check it out. Hello, everybody. What you see here is not a yalof picture of mine, though, it's the severance, according to Greek mythology, to Severals is the God of the underworld. And if I might recommend you one thing, don't mess with him. But on the other side, having such a sciberras as part of your software architecture, it's a very clever idea. Recently, I've talked about a lot this architecture here, this architecture, slicing a big application into domains, domains that don't know much about each other, because if those domains are loosely coupled to each other, then you can change one domain without influencing another one, without breaking another one. So here in this case, I have a booking domain. And according to my access restrictions, booking is only allowed to talk with booking libraries and have shared libraries boarding. Indurain is only allowed to talk with boarding libraries and we've shared libraries, but booking and boarding are not allowed to directly interact with each other. This the couple stem, and so I can change them individually without breaking down. However, the shared colonel for sharing things is not the last word on this, because as she colonel also means that you have some common libraries, libraries belonging to everyone and something that belongs to everyone at the end of the day belongs to no one. So there is a reason for a breaking change because no one feels responsible for it. And also you need to take care that you don't end up with a system where two thirds of everything and up in the south come. Such a system is not maintainable anymore, and you have still a high coupling now the coupling is within the shatkin. That's why in general, it's a good idea to introduce another building block, I am calling it the API. Such an API is only exporting selected stuff from one domain to other domains, for instance, only one or two services that are needed over there. And several people ask me how to implement such an API. Well, in this little demonstration here, I want to show you the answer. If you look to my. Application we see I have several libraries and there is a booking domain and within the booking domain I have an API and the API only consists of one index. Yes, this is my severals this is my godfather domain that is only exporting. Select that stuff from my domain, something from here, something from there, but not more. And only those parts need to be backwards compatible. It's really as simple as that within the boarding domain. We have several features and as you see here, those features can access the booking API. That's completely OK, but we are not allowed to bypass the booking API, for instance, by drilling into it. Still, mainly in this case, we get immediately those lending warning, telling us that a broad check back with domain boarding can only depend on domain boarding libraries, the booking API and SHERAZ. So as I see here, my architecture is really enforced for enforcing this. I am using some limiting rules within an annex workspace. After this session, Auvil uploads my examples to my blog, you can have a look to the next Chazen and that slim and that all those restrictions are configured. But for the time being, are just want to point your interest to one specific line within D-Link Chazen, namely this line here where I'm defining that domain, Baudin can access other stuff of domain boarding the booking API and the she had to come. As a matter of fact, such an repository has some more surprises, if there is a plural, I don't know, for instance, each and every library itself has an index. Yes, this is a Cerberus, a guard for the library. The API was a guard for the whole domain. And even if you look into my domain later, you will find the Sciberras, my domain. Leja is subdivided in three parts. The board in the middle is my domain model, my Kiyan site, and that is my client's data model and services operating upon it. And then here I have my infrastructure cut, which is mainly about the excess on the top, I have phosphates. The application layer consists of phosphates, which are orchestrating everything after the main model for specific use case. That means there is one for seeds bear use case. Four seats have been proposed by Thomas Burleson. That's why I'm also calling it a Burlison for seat. And that is a really smart idea, if you want to know more about it, reads thumbs block or look at Thomas presentation that has been recorded and she can to thousands and nineteen. But now let's have a second look to my example to see how I implement that idea of the Burlison visit. So in here, within my two mainly. We should see nothing because it's the wrong domain. Let's go into the right one. And here in there, we are finding application services and there is a flight for. And this flight for seats provides, of course, a public API, the consumer can make use of it, flights absorbable and the consumer can call as search as well as a methods. This is part of the public API. But the rest is a secret of the implementation of the fosset. That means I can change all those secrets here for the time being, I'm just using a behavior subject for state management. This behavior subject is exposed as the flight's observable. But later then I feel the need I could exchange this with a real store implementation, for instance. And sure, I could change the subject by a store and the consumer of the library. The smart component consuming the flights, absorbable, calling the search method will not even recognize. That means this idea allows me to introduce something complex, like an Sherak step by step only when I needed. This prevents me from doing both Obock, but also under engineering, I just make sure I have the freedom to introduce it when I really feel the need for it. If you like these ideas, you'll find out more about this in my free e-book, you can download it here. And at the end of the day, please make sure that your software architecture is using some severances. Have a nice day. And that was Manfred Steier with his thoughts on DTD. So something else that we've got to talk about is basically this a little bit creative. If we had the capacity, if you had the capacity, if there was a way to pick another project to do, and what would that project look like? And you can pick between something like a technology driven one basically to say, I'd like to do a new Blockin project and that's all right. Or something like related to an industry, something in the fitness industry, or basically that's where my head's at. But maybe maybe there's something to understand about what you're thinking there. Well, if you asked me a year ago, my answer would probably be different. But would it have been, um. Well, I don't know for sure. But with covid and a lot of changes over the last year, I think that it would be great to work with or build an application that helps certain industries that are struggling right now. Or or maybe there's there's new opportunities now because of, you know, transformation with health care. But I mean, technology wise, I have already mentioned being interested in kind of bridging this gap with the smart contract development and the and the Web development. Um, so something that, you know, allowed a team working on an angular application or a native script and a single application with the smart contract would be really fun because then members of our team would be able to work together that hadn't before. And and also I think we'd all learn a lot. Um, we definitely hit on we'd be firing on all cylinders if we got the the block chain thing that had to also be distributed to the mobile app store and that it needed administration from the Web. And we could throw in some email notifications in there for good measure so that there's something nice to do for an API. You got certain timeliness matters when you are building projects. It has to be a project for for the moment. And I think about the one that you and I have been working on for a bit. A lot of the things that we're doing with that, and I guess we can just keep it sort of vague. We're rebuilding an application that was built 10 years ago, but we're reimagining it with everything that's happened since 2010. Back then, you can do many of the things that you can do with smartphones and we're building some of that. We're get to do it for an enterprise and it's time in their life cycle that they get to do it. It is nice to think that there is something part of the broader world that would be something we could participate in. If there is major shifts that are going to continue where folks are working from home for the foreseeable future beyond the necessity of what covid driving if they're doing it just because. Well, that turns out to be a fairly cool way to work. And I guess we know that it is. But if everybody else seems to agree, what does that open up? You know, I like that. I like doing development. I like it more in twenty twenty and I did in twenty nineteen and more in twenty nineteen that I did in twenty eighteen just year by year. It seems like it's a nice thing to do, not only as a career but as a way to participate in society. You know, when we were talking about like I have a friend who is all right on Instagram as a marketer and has built a business on marketing on Instagram, but basically has no technological savvy. Yeah, yeah. I think that that comes up a lot. And that's why I mean, it's a great career for us because we're and for many people, you know, that start getting into it later in life too. They realize that. I think, you know, covid really push this on a lot of people, but you really need technology to to function in a lot of ways. And it can be really hard to break away at the same time. So there's a lot of there's a balance for us. Who are already on our screens all day and then I think, you know, it's becoming reality for for most people, but I've something that's changed for us since we started, I think was really focusing on, like managing the projects and making them, you know, making sure we communicate really well for our clients and finding the best ways to do that. And that's been, you know, trying different things. And yeah, recently we've always been working and an agile methodology. But yeah, more recently by, you know, getting certified with Scrum, I think that that's really helped us, especially with working with these larger and angular projects a big time, I guess, like being a quote unquote scrub master. Now, I'm not really talking about that like it's a part of my career, but it is basically a lot more of my day that it is software development now in some ways, so that the listener knows Upstate Interact is not the biggest company on the planet. For a while, everybody was doing every single job. And for us who are currently talking, we've been trying our darndest to make it so we can continue to enjoy the fruits of all of our efforts, learning how to do development. And at the same time, we're trying to work out how can we also be effective entrepreneurs. And what that looks like is we balance our time very carefully and basically do what we can to trust the development team in order to do development on some major tasks. And we now are just looking at how do we really well to find those major tasks so that it's clearly delivering value. Yeah, that's the biggest thing. Like what what value are we delivering? Every sprint, every, you know, time period of development that we're iterating through and for for our team. I think that has been really focusing on a common goal. Everybody is aligning around like what were what there are going to be working on together and what the goal is for for shipping. Well, and far from Frenchman is definitely it's the understated part of Scrum. If there is like one core thing that you can get from everything that you do in Scrum is just a well-defined goal for the short term. That is something that people can know they're going towards is transformational. Yeah, I mean, it sounds simple, but that's huge. And also all the up front planning, like with all with some of the biggest thing I think out of the scrum guide is something called the definition of done. And what does that mean? It can be interpreted a little bit, but you have a definition of done in your user stories that some kind of a quality control. And when do you want the development team know that this is going to be something that can be shipped? And and then it's it's also part of the iteration or the retrospective of the team works together to think about what what could we do differently? What can we bring to the next sprint to continue to improve? And I think that continuous reflection and planning has has helped us really stay focused on our goals to so and then finally, with luck and the management side for us, I think that like having the data with it, with tracking our velocity is is really great for planning and forecasting our workout. So how do we estimate what's going to get done? It's it's it's always a really rough estimate unless you can back it up with some some actual data. So that's been really great. We've really ran with velocity. That's probably I wouldn't have thought about it if you didn't mention. The second biggest surprise was how useful it is to have a measurable speed that you're working on. It's not always the idea of trying to get a perfect measurement, like knowing you're going sixty miles an hour on a highway. And it is really good to know basically that you're keeping pace and that things that were taking a tremendous labor previously are now smaller because of work that you've done. You've gotten better at it and you can look over time and see something I was previously a major for. Because you've been into it a while, there's less and part of it all this shot is you've got to have a big enough project to make any it is necessary. I'm not talking about major hundreds of people projects. I don't know what this does for that. But you've got to have a half a dozen folks that are full time working on something to make use of this. And I'm glad that projects that are of the well, the size that it's not only an individual challenge, but it becomes a team challenge. It's something that we can all try to work towards together and grow together. And that's why now we can jump into a segment that's got almost nothing to do with a key management, but it does come down to technical management. And this segment called a component of the show. And in this one, it's me. And I'm going to be going over how to organize your components into not only presentational, not only containers beyond that, also into type called pages. So let's have a look today. We're talking about components and they're going to be presentational components, containers and pages now starting with a page. What type of component is a page? It's one that's rooted two and it's one that gets data from the outside world outside of the component pages, workouts work out. Page two. Yes, file in this project includes a component that does not have a selector page is only ever routed to. You can forego having a selector as well. It's getting from facade analysis of how it's pulling from NPR and what the idea is. If there were any tracks or any other state management tool, it would be directly included here. And we can pull in some state from not only the state management tool, but from the root as well. So that is a page. It is a type of stateful component that includes the characteristic that in the way that it is accessed in the routing module and it is done never with the selector and always with a route. There is a presentational component directory that is briefly written and components and representational component is something that's well known. It's also statelets component. It's also just a dumb component by another word. Name in this project are called components that have the characteristic of a lot of the time being able to use change detection on push strategy. It means that it's only going to get its inputs from other components. And those inputs can be used to say that when they change triggered change detection, it'll also outputs. And when those outputs get emitted, then they will as well do change detection. This is fairly well established in the world of development and variables. Interior here are for local state. In this case, we've got a form and some other form builder manages the form and that does not go to the outside world through the changes to the form and any of the data that is input into the form, travel to the outside world through outputs exclusively. They are not sent to service. They are only communicating through inputs and outputs. And then we've got containers. Now a container like a page get some state from the outside world and the dust up with them. In this example, doing what might be by the NPR team considered a beuse or misuse of selectors that might say that this could be selected. Now, on the other end of it, this is a fairly typical container and that's a characteristic of it is got a selector, I mean, that it's going to be included in other components. And a lot of times in this project, the container is included in a page and as the property within the container, including certain elements and presentational components inside of it. And as a result of that, the primary comparison that you can make is that it's pretty close to a page and most. Folks will have a container's directory that includes what in this project is pages. Now, there are similar, but not exactly identical. And so as a result of building over and over and over and over again a specific type of container that's only ever routed to, it's been helpful to have them separately listed and organized. It didn't come from a theory that we need to have a selecter of this type of container. It did come from over time recognizing that the thing that's getting routed to is never using it selector. And that means that when I'm going into a schematic and I'm generating and I'm writing a component, I can make a little niceties for myself, like typing pages, work out, including it in the proper project. And at the bottom, I can do two conveniences, which are to skip the selector and then give it its type as page. And then the result of that, in the case of the pages workout's is that it's got that type written right into the file and it's organized right into the pages directory. It is part of developing large applications that we get into these types of thoughts and ideas. So that is all there is to say about pages. That's all there is to say about components and containers. They are simple things that folks have in their applications. And may you find ways to take what you've seen here and put them into your own. Hope you guys enjoyed that last segment, I just wanted to touch on something that Peter mentioned earlier about our weather, whether adopting scrum on a team smaller than six is is worthwhile. I think that that's I think that's worth a discussion because there's there's parts of it that really can be worthwhile with a small team. But there's parts that may be more time than it's worth. And I think that it depends on on your team. But the the velocity piece, I think adds a lot of value when you want to transfer, like, you know, say I work on one project and you want to and you need to know, you know, how to estimate your work on another project to put proposals together. I think that that's that's something that can help. But overall, the what we talked about, we like the goals and the quality control and all of that could be a smaller scale. I in contrast, starting with the idea that I'm well aware from and out of that, there is this project that's got the six Volks on it. And there's this other project now that is basically me doing the angular development. I'm able to be productive in that, not only because I'm having done ANGULAR for a number of years as well, because it's a rebuild of an application that I've previously built. So with me on that, there is a product owner that defines what is that the user actually needs, what is a client in this case have to have in this version that didn't exist in the other? And while I'm doing the end, there is another Fallada in the API for all this, the hold back and is going to be written. And so we're about a total of three, you know, physical human bodies on it. A say between all of us. It may be a full time job. At the end of a single week. We might get up to 40 hours between the three of us. Now, even though we're not really making anything major, it is useful for a breakdown of how do we all interact with people related to the project. And it is useful in so far as we're talking about complexity. So even if we're not doing the dailies, we're not doing major velocity tracking. We are able to say they need to be able to have that new module built out in a way that exactly duplicates what it was previously. It's so similar. It's like 13 if we're using Fibonacci and then we've got this other new thing that we haven't done at all. And holy cow, we got to do some data visualization in there as well. We're going to project that right up to a twenty one. And by the way, it's probably, according to the product owner, the thing that they need the least. So given that it's as complex as it is and it's not as important as some of the other stuff, probably shows that for the backlog until further notice. It's all right. You know, it isn't like it's just six people full time. Yeah, so there's definitely things to take away from it for sure. Certainly changed in the time since we started where we used to call Agile and what we now practice a scrum. And certainly you would agree that we've gotten better as developers by having some better product development framework or methodology to work with them. Oh, definitely. I mean, it's just helps with consistency. But for me, it's really about communicating our progress and value to our clients. You know, I mean, anybody who works in software development knows that when you estimate something, it's it could take at least twice as long. And so prioritization matters of user research and understanding matters. Presenting progress and value to your client matters in order to iterate. And so I think that having a framework can really improve the way you work with your client and the way you work with your team as well. You know, on a different note, those two different projects that they're both being built out nebular are a lot of what I believe provides is that structure for consistency so that no developers can work on it without doing any bike sharing. I always like to say that it's just the sort of like the ruby on rails for modern front end client development. It's like batteries included is what folks that about rails just gives you everything you need. Angular basically gives you everything you need. And what people tend to when they talk to me about Angular coming from a background or review background, they tend to think about each of them as being able to solve different problems. And certainly they do. Specifically, if you try to ask where is ANGULAR going and does it continue to be for certain types of projects or does it go more broad? I'm thinking back to an energy video that was maybe of twenty nineteen where the team building is aware that they've made it real nice for a like a particular part of the curve, which is like the chunky middle, especially where a lot of apps live. It wasn't at the time being super developed with the sense that it could grow for the absolute largest applications. And there was a Google developer that was talking about it. So they're talking about it wasn't quite right for the absolute biggest applications are Google or go figure, they're not able to use an off the shelf framework for what are, in effect, the world's largest applications. But then on the other end of that scale, they also were stating that the future was making it appropriate for smaller applications. And we haven't heard so much about IVI, one of the side effects. It's going to come from that and it's being chatted about is that there is no longer an absolute hard requirement for an angular module. Basically, you could develop components that could be individually loaded, and that might mean you could do some real fine grained selection of what code to include at the build time. And where that leads to is ultimately a smaller application. And so it's like you can build a really small application with some of the newer things. And that's just something that I'd be curious to see. How does that evolve over the 2021 especially? It's nice to think about the Web just year by year. It's about as far out as I can think to do it. Yeah, yeah. That's a good point. And it'll be interesting to see. And it's also interesting to think about how we're going to be transitioning into using Anex next year as well and and what that's going to look like for our product development with like having a number of applications and built in having our team build them out. And you know how that's going to affect team management. And, um, yeah, that's the technology seems really powerful for the application that we're building. Yeah. But I guess it's probably because we're coming to the end of 2020 and I'm thinking in terms of year long reviews and things, when we first started this project for the Enterprise was maybe 18 months ago, we did a. And acts as related to explode, and I think there were some good reasons that we chose to go away from them. One of them that is certainly stuck out for me in the decision was we're now building on top of the anger there, Seelie, with some other key ally, and he felt very uncertain of if it would have a life and how long. And so here we are. Of course, we're going to go forward with it. It's fantastically productive way to build multiple applications. And as we've got to have a couple of applications for a single is just real nice. It really has come along. The folks that built that are doing a nice things, I think I've got a I think we've got to commit, by the way, on their repository. Oh, yeah. Doing what? I was so frustrated. They've got something called when you're building an engine or actually affect, you know, that you can do you're like of type operator and not a switch map. So they've got their own operator. That's for router navigation. It's like this effect in response to somebody's going to this rally will activate a certain anger Angiomax action. And I couldn't figure out for the life of me how to make it work. I tried so many things and it turned out that the documentation was it was just incomplete, if you wanted to say like that. So I think my comment is basically after spending three days in the community chat and figured out how it works, well, we all came to realize of the missing bit of information. That's what makes opensource so great. Yes. Oh, you know what? It's so great from that that you took that well for other people, not for you. But let's let's bring it to into a closer everybody howzat. Let's jump into the last segment. Thinking that this one is a good way to Tulita for real is from Jeff Wellsley. And Jeff is the CTO of Get Human. It is a website that does what few, I think public websites do, which is deliver SEO at like its best in class, get human delivers you information about how to get in contact with the customer service of Amazon or from AT&T, any major company that's got a one 800 number. It does more than that as well. But basically it needs to be competitive. And Google just devoted a number of public docs to it. And in this one, it introduces us to some of the most meaningful numbers of a CEO and talks a bit about how it relates to ANGULAR. So let's close it out with Jeff Warbly in a segment called Wow as CEO. The perfect set of lighthouse scores. Wouldn't it be awesome if your webapp had scores like this and not just awesome to show off to your friends, these types of things have a substantial impact on your SEO, which should affect your bottom line. These last four numbers are, relatively speaking, easier to achieve, typically in House, when you run the audit report, it'll show you some errors. If you don't have 100 in any of these and you just fix those and then eventually you'll get up to 100. This last this first one, though, is much more difficult to get to 100. If we look at the light house scoring calculator for performance, this is sort of what you need in order to have 100 and it's really tough. In fact, I would say that unless you have a literally static website with no client side JavaScript or interactivity at all, you cannot achieve these numbers. It's just nearly impossible. Now, if we adjust the numbers a little bit. It is possible to get a 99, it's difficult, but it's possible with a client side JavaScript app, you could see that the key numbers here are the first content will paint, you know, about a second the largest content for paint, which I'll talk about in a second, about two seconds and then timed interactive about three seconds. Those are the key numbers. Those are the magic numbers for HCO, even though performance is a separate category in Lighthouse than the category, quote unquote, Ezio. Really, this has a substantial impact on CEO as well, and if you can get these magic numbers, you will rank very highly. So how do we get to these let's talk about each in turn and the first content will paint is probably the one that people who have some sort of knowledge with ASIO are most familiar with. It's basically achieved through server rendering for the most part. So if we have a singular universal, we can render our site or whatever JavaScript framework you have sort of rendering framework. And we're good there. For these other two largest content, for paint and cumulative layout shift, I sort of highlighted these together because they're somewhat related. Basically the first content will paint is that very first view that the user sees and which typically comes from your server, you. But then the client side boots up and it may or may not make a bunch of changes and render parts of the page, the cumulative layout shift is also referred to as Genk. It's when things on the page start moving around and it is something that is extremely detrimental to your users. So Google very heavily monitors this and will view it as a negative signal if you have Genk on your page as your JavaScript is loading. That's why even with some of these other numbers that have a little bit of flexibility for cumulative layout shift, you can't have any and that can be very difficult. So no layout shifts, no jank whatsoever. But even if there's no jank, there's still is some parts of the page that might render just on the JavaScript on the client side and fill in later. That's that's a very normal thing. And so it's not a big deal for that to happen, but it has to happen quickly. So your first paint occurs very quickly about a second. That largest content will paint all the rest of the stuff basically has to come in within, you know, less than a number another second and achieves it is very, very difficult to achieve these when you have a full client side app booting up and re rendering the page. So I have found from my own personal experience that it is difficult to impossible to do this with booting a normal angular client side app. And what I have to do is use something like angular elements, basically, where you have just a sprinkle of JavaScript, just a part of the page that is rendered by JavaScript and not the entire thing. You don't have something taking control over the entire page and rendering it. You're just rendering parts of it. Angular elements generate web components which render just small pieces of the page. For the speed index, this is something that I'm not actually quite sure what the value lighthouse has in separating this out from the other things, because, quite frankly, if you're first Contempo Paint is very good and your large content for paint is very good, your speed index will be very good. Speed index is basically where they measure the progress of rendering across time. So if you're page kind of renders quickly over a period of time and like I said, this should come with the other thing. So I'm just going to check this one off. And finally, our time to interactive and total blocking time I'm putting together, because this both has to do with JavaScript loading and blocking the main Web thread. So you really can't have any blocking time and time to direct when a user can actually interact with the page has to occur very quickly. For total blocking time. The only good way to achieve this when you are using JavaScript on the client side is to have that JavaScript run within a Web work or something off the main thread where it's not blocking the main thread. It could occur very quickly where it doesn't affect the user. But typically both, you know, Lighthouse and your audit and the Google crawler, as it's rendering your page, will be detecting this and ideally trying to see that there's no blocking time whatsoever, which really requires you to run your JavaScript inside a Web worker and then time to directive related, but somewhat separate. You know, when a user can actually interact with the page, you know, if you are rendering your JavaScript or running your JavaScript within a Web worker, the time detractors should be really quick as soon as the elements are actually rendered on the page. However, there is a slight issue with when a user starts typing into, let's say, a text box. But JavaScript hasn't loaded yet, so it isn't actually detecting that. And you might run into some issues there. So there are a couple problems with this. You do have a little bit of time to load JavaScript here. So there's a couple of different solutions for this. One of them not not the only thing, but one of them is using angular pre-built, which actually records what a user is typing and then passes it off to the client side elements or Clydeside app when it's when it's loaded and booted up. So that's just one potential option, not the only one. Now, with all of these solutions, I will say that I have put together a variety of different apps that meet these scores, get in 99 in performance, perform really, really well with SEO and using the things I've kind of laid out here. I threw them out there as a way that might be familiar with people, because I'm sure that if you know angular, you've might have heard or used angular elements or previewed. And there is actually even a Web worker within ANGULAR that you can utilize. So these things are there, but they're tricky because there are a whole bunch of things that you need to pitfalls you could run into that then affect that you aren't. You start blocking the main thread or you you start Jianqing the page accidentally or et cetera, et cetera. So well, this set of solutions will work to achieve these magic numbers, which will give you a huge boost. It is also a tricky set of solutions. So more recently, I have started using a different overall set of solutions, which basically involves the universal necessar for that initial view that generates an AMP page and AMP takes over from there. So AMP is a technology developed originally by Google to deal with this specific problem. It was literally built with this type of thing in mind, with performance and the user interactions and giving users a great experience. So not surprisingly, AMP has built into it hard coded into it, a that it will meet all of these numbers almost by default, almost by default. It would be very they almost make it difficult for you to not be highly performance. And so it is somewhat restrictive, but it also brings huge benefits. So. I know that most of you might not have tried to amp it is it is something that is different and would be in addition to ANGULAR. But if you are interested in achieving these types of magic numbers and ranking highly in Google, it's something that I would highly recommend. Thanks for listening and talk to you soon. Well, that is our show for today, and we're going to be putting these out once a month, so we look forward to having you back at next month's show and see you then. I'm Peter Smith, Zoe Augoustinos. And let's say, everybody. We're glad to have you as our viewers. We're so glad to have Engy confess our host and until next time. Good night.

Blog

Best JavaScript meetup videos from January, 2021

After our latest JavaScript meetup video selection from 2020’s finest, we’ve brought a new collectio...

Read more >>

Best Angular meetup videos from January, 2021

After publishing our Top 10 Angular videos from 2020, we’re finally back with January’s finest. Rang...

Read more >>

Top 10 TypeScript meetup videos in 2020

Ever found yourself wondering what happened in the TypeScript scene in 2020? Well, look no further, ...

Read more >>