Angular Connect 2019 | Day 1 Track 2 Livestream | Sponsored by ag-Grid

. . . >> Hello, and welcome back. Sorry we're a bit late. We're running a bit late today. But just getting going again. In this track, next up is Asim from Microsoft. He's going to be talking to us about how to save the world one line at a time. He will be tomorrow in the performance expert zone. If you want to chat with him and find out more, chat with him at 1:25. Without further ado, let's welcome Asim to the stage. ASIM: Hello, everybody. Thank you for coming to my talk today on saving the world one line at a time. Did I say that right? Online. So, my name's Asim Hussain. On Twitter as jawache. I blog about various things on my website. I got the Dev, first, right? And I also am a developer advocate at Microsoft. I actually lead advocacy. Regional developer advocacy. And we have a stand outside today. Come and chat with me later on. A whole bunch of different things. All right? I'm also pretty environmentally conscious, okay? Have been for most of my life. We recycle as a family. I don't drive like a gas guzzling. I have a lightweight car. I do grocery shopping in a market that doesn't have lots of plastic. I carry insane-size plastic bottles around everywhere. If you see me in an airport, I'm looking around for a refillable tap somewhere. That's me. These are things that I'll do for the environment, okay? My son, Micah. 10-month-old. I'm not too sure what it is about this picture. I just get the impression that he loves his dad. And something that we agreed on when he was born is that I would do all the nappy changes. We have some -- I would give him. It was really great advice, actually. It's quality time I spend with him on the nappy changes. And my wife said, actually, we're gonna use cloth nappies. Well, disposable nappies, no, cloth nappies. Any parent in the house? Any cloth nappy users in the house? Well done, well done. You know the pain that you talk about, right? Basically you suck it up, right? With a disposable nappy, you're going to do a shit, tuck it away. With a cloth nappy, you have to deal with it. Wash it. You don't throw a cloth nappy away. And he shits eight times a day. That's a lot of shit. A lot. Okay? And just for months was covered in shit. I would be on like meetings talking about, what's that on your face? I would say -- I would be like, oh. That's some shit. Anyway, that's what I would do for the environment. That's what I would do. Be covered in shit. I was happy to do it. It's fine. Right? Then I had like an epiphany like four or five months ago. I was like, I realized, like, I was willing to deal with shit eight times a day. I was willing and happy to do that. And yet, I couldn't remember a single time in any scrum meeting, in any point where we had to make an architectural decision about an application, I couldn't remember a single time where I'd ask, well, actually, what's the greener option? Not once. We'd sit there and argue for ages about what's the faster technology? What gives you better SEO? What gives you better performance for the end user? What's a cheaper option? What's -- what option has the least risk, least bug? We'd argue about this hours on end. But not once had we ever said, what's the green option? Actually, what does that even mean? Terms of what we do as technologists? Web technology today. What does that mean? How do you make those decisions? That's kind of the journey that I've been on over the last quite a few months now. To hear, and that's kind of what I'm going to talk about today is, well, A, why are we talking about climate change now? Why are you hearing about a lot more? Right now. And what does green mean? Like what should you do? Should you start walking around wearing hemp sandals? What is it? As technologists, what can you do which has the most impact? Some of the things I will talk to you about as well. And also, what other things can you do today? Because as technologists, we actually have a huge amount of power and influence in this world. Right? There's a lot that we can do and there's a lot that we can help. what can we do today? All right. So, why now? Why is everybody talking about this stuff right now? One thing about me is, if you have been to some of my talks before, I like to make things a little bit interactive. There's usually quizzes. Ask the audience. I'm going to ask the audience now. All right, so, there have been five mass extinctions. There's five mass extinctions in the world. That means that where either half of all life has died, right? Five. The first one was 445 million years ago. How did it happen? Any guesses? Yeah? Climate change. I think this one was a whole load of eruptions happened not over like a year, but over like a thousand years or something like that. In the atmosphere. All right, second one, 375 million years ago. 75% of all life died. Any guesses? Climate change. Exactly. There you go. Next one, the big death. 95% of all life died. 95%. Okay. What was it? An asteroid. Ah. Now you're thinking. He's going to mess around with you, aren't I? What's the next one going to be? Go on, next one. 100 million years ago, 70%, what is it? Climate change. There you go. Now, I'm still screwing with you. It's like, what's the next one? You know, I wouldn't be messing around with you, Asim says, what's going on? Huh? So, the next one. 6 million years ago. That dinosaur looks very familiar, doesn't it? 75% of all life died. What was it? Both. So, it was a whole load of climate change. And then an asteroid came along and just took it over the edge, right? That's the prevailing theory. A lot of climate there, right? That's the prevailing theory. And right now people talk about how there's a current one happening at the moment. Okay? So, whether you believe it's manmade or not, it kills. It just kills. That's the fact. All right? It's just a fact. What is it? Just to give a -- a summary. So, basically we're talking about something called the greenhouse effect. There's greenhouse gases in the atmosphere. Carbon dioxide is the main one. It's like a blanket on the planet. It just heats it up as energy comes in. Traps the energy and keeps it inside and doesn't let it escape. We need some in fact atmosphere, otherwise the planet would be Fahrenheit. I don't know what that is in -- very low temperatures. We need some in fact atmosphere to keep the temperature. What's happening now is we're pumping a whole load up and makes it warmer. Just to give it a little bit of a -- so, you can talk things in a -- just explain some terminology. To talk a lot about carbon dioxide and carbon in the atmosphere. Something we're talking about, a carbon dioxide equivalent, made up of different greenhouse gases. Carbon dioxide. Methane has a much higher greenhouse effect than carbon dioxide. 1 ton is equivalent to 25 tons of carbon dioxide. That's why we collapse it into one metric, the carbon dioxide equivalent. That's what we believe is going on. That's what we believe is causing climate change. 97% of scientists agree that climate change is happening and that it's manmade. This is through a study of thousands of papers. And I read that, two things struck me. Which was like, 97%. What if 97% of people agreed on anything? And then I thought, who are those 3%? Who are they? What do thing is happening? But I did research, I found a website, it's interesting, called skeptical science. What they have done is taken the 2,000 papers and done additional science on them. And by expertise in climate science of the authors, okay? What it showed was a more of an expert you were in climate science, II, a climate scientist, the more you believed it was happening and it was manmade. The less of an expert on climate science, the less you believed. The more intelligent you are... the climate change is happening. And it's manmade. I'm not gonna argue with anybody. There's people in this room, every time I give this talk, there's someone who heckles me, and argues with me. The 3% of the audience. I'm not talking to you. That's not why I'm here. It's happening, it's manmade. A number you might have heard about. 1.5 degrees. In 2016, 192 states agreed in the Paris Agreement to try to keep the temperature increase on the planet 1 .5 degrees. Less than 2 degrees, ideally less than 1.5 degrees. There's already a 1 degree increase in temperature. And now there's another number that blew me away. It was like 2, 1.5 degrees. I couldn't tell the difference. Such a small number. That can't mean anything. Why is that so important? This small number? I did some other research. There's a great website called carbon grief. Which has collected a whole bunch of information from other sources to look at the effects on the planet from the different temperatures. You can see at 1.5 degrees, 1.5 degrees. So, this is the proportion -- this is one of the slides. The proportion of species losing 50% of their climactic range. When we get hot or cold, we take clothes off and on, right? Something like that. Animals and plants can't do that. They just die. So, basically 1.5 degrees. You can see there's mostly single digits. All right. But we need insects, right? There we go. 2 degrees. Getting into double digits. Yeah? Maybe, but not great. 4.5, we're pretty screwed, right? Pretty screwed. It's a really bad place to get to is 4. Right? That's why those small numbers is really, really, really important. And here's the thing. Here's the thing. To remain below the 1. 5 degree limit, we set ourselves up for that very reasonable limit that we can comfortably survive in, we would need to cut our carbon pollution by 45% by 2030. 11 years. Right? And we need to get to zero by 2050. We're nowhere near -- not even slightly a little bit close to achieving those goals. Right? We're not even at the point where we are reducing the rate of carbon pollution. We're actually increasing year-by-year. It's increasing by 5% every single year and has been for quite a while now. We haven't even reached peak pollution to start going down, right? To remain at a 2 degree C we need to cut by 20% by 2030. Still an incredibly challenging thing to achieve. Zero by 2075, right? And that's why everybody -- that's what you're hearing about it. That's why everybody is getting pissed off. We're not on track. Not even remotely on track. Not even close. Okay? And that's the thing. It's not like one person has to do one thing. Everybody has to do one thing. Every country has to do one thing. Every country has to do a thousand things, right? And that's where we get involved. Because we can do something. And we can have an impact. So, what does green mean for us as technologists? What does it mean to provide a green application? There's many things you can do. You can worry about acidification of the oceans, you can worry about plastic consumption. There's many different things you can worry about, right? For us, the easiest way for us to have an impact here is to look at electricity, okay? Electricity, the creation of electricity is responsible for 30% of the greenhouse gases of the pollution that is going on. And that's because 80% of the electricity is created through the burning of fossil fuels. All right? So, if we make your apps use less electricity, that's a really simple, clear and impactful way that you can do something positive for the environment. And you are technologists. You're not just doing it for yourself, you're building something that is used by thousands, tens of thousands, millions of people. So, you actually can have a really big impact in this world. You can have a really big impact in this solution. Right?Let talk about this. Let's talk about it from multiple different angles. I have been speaking to quite a few people over the last six months to kind of figure out where I should be spending my time and effort. And I'm hopefully going to impart this on to you. There's kind of three parts in what we build. We have the client frontend. The networking which you don't think about. But the network is actually just loads of computers at the end of the day. And then we got the server side as well. The end computer. So, looking at the frontend. Okay? The client side. All right. What uses -- within the same task, what uses more electricity? Desktop or laptop? We reckon the desktop uses more electricity. Who reckons laptop? Oh. Desktop uses more electricity because laptop is powered by a battery, right? Anything that's powered by a battery these days has a lot of effort to improve battery performance. So, actually, if your laptop's actually very, very efficient compared to a desktop. The desktop, they don't really care. They know they're going to be plugged into the electricity. They have all the electricity it needs in the world. There's no need to optimize that hardware so you use less electricity. Actually on our phones, our mobile device, our tablets, our client-side frontend world is moving off of battery-powered devices which are making it very, very efficient. And even things like Chrome and the browsers. And imagine these things. They really focus a lot on battery performance. It's how we build, right? Okay. But then it kind of -- then you don't have to worry too much about the frontend. There are things you can do. Maybe also wonder about, well, what kind of language you would be building our applications in? Some languages solve the same problem are going to use more electricsty than other languages, right? There's a study done. I'm going to show you a screenshot. And it's going to show you that the language, in the first column. And next to it is going to be how much -- how energy efficient it is. The top one is going to be most energy efficient. The bottom one is least. You're going to start scanning it. As soon as I move the slide forward, one, two, three. There you go. We're kind of like JavaScript, five at the bottom. TypeScript is -- I think it's included in the time for -- that's fair. It's the same as JavaScript tend to run. But right at the top is like C and Rust. Probably not going to be building my frontend applications in Rust just yet. But it's quite interesting, right? Maybe build a server side application. With the efficient technology. And then it makes you think about WebAssembly as well. Makes you think of it in a different light. WebAssembly is not in the report, but if you think about it, compiling things to WebAssembly is going to make things much more efficient to run. So, the network, okay? This is probably where you have a much, much more impact on the work that you do if you want to reduce the carbon impact of your applications. Oh, another question. Here we go. Wi-Fi or mobile network? What uses more electricity? You reckon it's Wi-Fi. He who reckons 3G/4G? 3G/4G? It's seven to ten times more. Using towers and stuff. It basically does use a lot more electricity to transport the same amount of megabytage down to the devices. Some things you can consider. There's a network diagnostic API available in quite a few browsers now which will actually tell you the network. If you're on a 3G/4G, perhaps consider using that additionally serving different types of data. There's lots of studies -- they're very, very -- this number is changing a lot. Take this with a pinch of salt. But this is kind of an average number that I found which looked pretty reasonable across all the studies about the amount of carbon that's generated per megabyte of data transmitted, right? 10 grams of carbon. Is that a lot? Is that a lot? I don't know. What is 10 grams of carbon? What do they look like? I find it very hard to conceptualize what this really means. And I found this site, Tweet farts. What somebody figured out is through the Twitter infrastructure, if you send a Tweet, it creates naught .2 grams of carbon. That's exactly the same as a human fart. Every Tweet is equivalent to a human fart. There's another way of thinking about it. Especially 50 farts. It's easier to conceptualize, isn't it? 50 farts. That's a lot of farts, isn't it? A lot. The average website is 2.4 megabytes, still. 2019, still 2.4 megabytes. Or... you have a website. There's already a lot of pressure on us to reduce the amount of data we send down the pipe for our websites. But it's just another reason to think about it. Okay? Another reason. Reducing the amount sent on the network can have a far greater impact than anything you can particularly do on the frontend for optimizing code. Optimize the data that gets sent down. Oh! Another one. So, REST versus GraphQL. Who thinks thinks REST? Who thinks GraphQL? I think it's GraphQL. I think it uses less electricity. On the client side, you can say I want the subset of the data. And it's going to reduce the amount of data sent down the bandwidth. What I'm doing here, I'm making you think about what's the greener option? That's the goal here. When you're sitting there in your organizations, you're going to discuss -- you're going to be making architectural decisions. Just start asking yourself, what is the greener option? And just start thinking about it. I don't know what the answer is. I don't always know what the answer is. But just start asking the question. Just really quickly, move forward on the server side, there's lots you can do. You have much more control on the server side. It's something you control and you own. You can control how the electricity gets consumed. Serverless is a really good solution I particularly like in terms of this. So, for those who don't know, serverless technology. If you don't use serverless, then you deal with servers and you have to figure out how many servers you need to deal with your load with the backend. And if you scale it up and down. And oftentimes, you scale too much and you get too many servers. That's just wasted electricity. Or worst case, you scale down and the bad performance for the end user. All providers have a service platform where we basically give you exactly the amount of computer you need to solve your problems, nothing gets wasted and the rest of that stuff gets used for somebody else, right? That is serverless. And serverless actually has a benefit in terms of environment because you don't waste electricity. I read a statistic the other day. It was like 30-something percent of all servers in the world are in a comatose state. Comatose. Comatose has a specific definition, which means it hasn't had any activity in six months. Right? Six months. And those -- you might not be using the electricity, but it still requires electricity to keep it physically in a data center. That's important. Serverless, auto-scales. Which is what's important. And you only pay for what you use. A little plug for what we're doing. Microsoft, my team, specifically my team internally, we build a product called Nitro. It's in alpha. It's basically building backends for application on serverless. It's based on a Nest. js framework, includes database and support. You can write it is a nestJS application. And you can see me at the booth and I have a demo. All right. Move on really quickly because the best thing you can do, the best thing you can do on the server side is just use clean energy. Right? I said before, that electricity is -- most electricity is created from the burning of fossil fuels. Data centers can actually go, we're only going to use electricity that's created from renewables. If you want a data center which is doing that, you can go wild, right? Because that electricity is not creating a carbon -- any carbon gases. Two people, and I'm so glad my company's one of them, that would make my life very weird. Two companies, Microsoft Azure, Google Cloud, both are carbon neutral companies. Everything we do is offset through carbon credits. Even my flight. Including our data centers. Everything you use in terms of anything is offset. Carbon credit. I'm also having renewables as well. We're trying to get to 100% renewables. Google Cloud is actually the same. They actually beat us on the use of renewables. But still both 100% carbon neutral. And it's also not clear cut, the data we have. They're not a carbon neutral company. But if you run your workflows in these four data centers, those are the only four data centers or regions, I should say, which are carbon offset. Dublin, Frankfurt, Oregon and -- and any of the others are not carbon neutral. Okay? And I'm a bit late. A few more slides. So, what can you do today? There's a couple of things happening right now. Well, the one thing you can do is join a community called Climate Action Tech, okay? A fantastic community. It's basically at the end of the day it's a Slack group. You can go and sign up. And they join you every Monday. It's a wonderful Slack communicate. It's not like a standard, there's no funny GIFs all the time and stuff happening. You can ask honest questions and you get lots of people who really, really want to help and give you lots of answers. I have been connected to so many people and plugged into so many initiatives because of this, right? You really want to get involved. Very climate stuff. We have seen people, oh, we work at the same company together. Oh, god, you're in the same room as me. You discover people that way. There's a climate strike happening all over the world, youth-led, Greta Thurnberg. Most of us are not youth men and women. There's a big movement happening right now where they're going basically you're screwing up our planet. We're going to have to live here for the rest of our lives. There's a big climate strike happening tomorrow. In fact, of the five locations in the UK or in London, one of them is just outside this conference tomorrow. So, part of tomorrow, I'll probably be standing outside there as well to show my solidity. You can join a climate strike. Go to Digital. global climate strike.net. And you can go to my website right now, see this banner at the bottom. Tomorrow it will be greened out. Just one day. I'm striking my website. And on the next, it will come back again. Climate strike, you can add that in. A bunch of companies are getting involved. About 5,000 websites. Big names, Dev 2, Ben said he was joining yesterday. Dev 2 is hopefully joining by tomorrow. These are the ways you can show solidarity. I will be having some stickers on the Microsoft stand tomorrow. Put them on your laptop. Just put them wherever. Show your solidarity to the strikers. Start talking. So, talk to anybody. It's fine. I give -- I host a climate action call every other week. And most important thing is just start talking to the people in your company. You will be surprised who else is actually interested in this. If you're in London, there's a meetup group called Clean Web London. They have a meetup next week. I definitely recommend going to that and connecting with people. The most important thing is to connect. Just to summarize, okay? It's a climate emergency. We're not only track to meet our targets. We really need to meet those targets. What can you do as technologists? Reduce your energy and electricity that's being used to run your applications. All right? One thing you can do. Use clean energy if you can. This is the big one. In fact, if you join Climate Action Technical, they help you to have the conversations with management to convince them to go carbon neutral. Again, join Climate Action Tech. And striking, you don't have to walk out the front door. striking can happen in many ways. You can have a conversation. I'm going to be striking tomorrow by standing at the stand, the booth, answering any questions anybody has about climate change. And helping them. I also have lots of stickers as well. Thank you very much for your talk. For my talk. Thank you very much for my talk. And yeah. Talk to me any time. Cheers, bye. [ Applause ] >> Thank you so much. There's a lot for us to take away from that. And you thanked yourself. So, we've got a five-minute break now. And coming up next here we have Angular and the OWASP top 10. In the next room we have servers for your Angular app. See you soon. Thank you. . . . . . . . . . Angular and the O OWASP top 10 Philippe De Ryck Welcome to Angular Connect ! >> Hello and welcome back. So, here we're going to be hearing from Philippe about Angular and OWASP top 10. You can catch Philippe later this afternoon at 2:00 in the expert zone. If you have more questions or to want find out more about security, catch him there. Without further ado, let's welcome Philippe to the stage. Thank you. [ Applause ] PHILIPPE: All right. Nice to see a full room for security. So, I'm always enjoying that. So, I'm gonna introduce you to the OWASP top 10 in the world of Angular. Essentially for those who don't know the real meaning of the OWASP top 10, it's an awareness document. It's created by the OWASP Foundation to raise awareness about the really dangerous problems in web applications we face today. Today is irrelevant, they have a new version every couple of years. They build a new application for the problems and the impact and how prevalent they are and how easy to exploit. They create a list based on that. You can see the 2007 version on the screen showing you what the problems are in 2017. This is the OWASP top 10. I'm going to talk about how how the OWASP top 10 applies to Angular applications. Because angular lash applications are different. They are not web applications. You don't generate on the server and send to the browser for rendering. No, you load the application with traditional requests one time and have your single page application loaded. And at that moment, we're essentially calling APIs and doing things on the frontend. That mean it is we're talking about Angular, it means first of all that we are kind of separating development. Yes, you can build things together, but you have frontend and backend Devs, especially in a large organization. Whether it's the same person or not, it's different roles for potentially different people or one person who has to split his time between the two. So, for the OWASP top 10, this kind of means a few thing. So, for example, injection is a serverside problem. Injection means SQL injection, commands injection. Possibly problems on the server. In the frontend, they're less relevant. I wouldn't say extremely irrelevant. But in my opinion, we can rearrange the OWASP top 10 to make sense for Angular. This is a personal, biassed view. Maybe you don't agree with that. I'm happy to discuss that after the talk as well. But these issues matter for Angular Devs and some are less relevant. I'm going to talk about three of them. I know it's called the OWASP top 10. But two are I felt irrelevant. I have 27 minutes left, I tried more. And that was 90 minutes. I'm not going to keep you hostage. Let's talk about the top three. And I'm going to start with process scripting. Process scripting is a really, really nasty one. Essentially where you succeed in executing JavaScript code in your application. And it occurs any time some untrusted data ends up in the page, there it is. Any time you have a message from the date base, the API on the backend, turn it into the page, you can cause problems and they are everywhere. And it you want if you want to see how prevailing latency it is, every application will have them. And recently saw one, one of the most secure pages in the world, the Google search page. One input field. But because of browser behavior, there was a cross-script in the behavior. That's the bad part, the sad part. Let's talk about Angular. That's the good part of the story. The Angular team knew what they were doing when they built Angular. Thank you for that. Let's look at what this means in Angular. On top you have the untrusted code. This is I know Angular code. You put untrusted data in there. Untrusted data is coming from user input. Doesn't matter how it ends up in the application. Whether from the database or from parameter or on input field. It's the value that matters. In this case, you see the value, hello. That's kind of expected. Somebody gives you extra data. An image tag. It's going to load unicorns of PNG. It doesn't exist and it has an alert and then gets executed. This is the Texbook example for cross-app scripting. This will also work in the scenarios that you're trying to exploit. Interesting. A side note here, the alert is really annoying. Like this pop-up in the browser and you have to click it away. And it keeps coming if you keep executing this payload. It annoys the hell out of you, but it's not dangerous. This is a simple proof of concept. A real attacker is not going to have alerts unless they want to show the vulnerability and collect the money. The moment they can execute JavaScript, they can do whatever they want. If I can execute JavaScript in your application, I can make it into whatever I want. I can start using APIs. And if use the webcam, use the microphone, get location information. I can deface your web page. They only do that, you got away very easy. That's good. That can start sending requests to the back end, to the name of the user and there's basically nothing you can do to stop that. The scripting for Angular means game over. The moment this happens, if the attacker is skilled enough, you lose. There's no way to recover. So, it's really, really dangerous. How does Angular handle had? If you output in Angular, it sees that. It's not stupid. It knows well, hey, I'm but thing at that time into the page with the curly brackets. That's what this means. I'm going to make sure this is seen by the browser. The browser knows, oh, this is data and it's going to show you the data. So, in this case, that output is safe. That output will never trigger the execution of script code. In no circumstances. Because everywhere that Angular applies something called strict conceptual escaping. You're putting this right here and I know these are dangerous there. I'm not going to allow that to happen. They have recovered. That's good. This is awesome. Old applications, Java server pages, ASP, you had to do this yourself. Modern applications, server side frameworks have something very similar today. But Angular applications on the frontend. Angular is not alone. React does it, Ember does it, I'm pretty sure Vue does it even though I'm not familiar with it. And so on and so on. This is good. This is a massive step forward. That's awesome. Of course, outputting HTML. If you want some fancy output, your business users are not going to be happy. As a rule HTML instead of images and paragraphs. This is only used for a shortcut cut that's going to work. There's no HTML in your name unless you're really unfortunate. But you will have problems with HTML. I can guarantee that. Say you want output that contains HTML. Angular has an HTML button. It's not a DOM-based HTML, it's data into the DOM. If you give it output like that, that's gonna happen? Angular is going to say you want some HTML in the output. So, well, actually, you get the image. Well, if you don't get the image, because it doesn't exist, if you don't get the alert either. Because what Angular does here is it knows, like, hey, I'm putting stuff. I'm putting untrusted data into HTML and I know that's a cause for major problems. Angular knew that in Angular 1. They gave an error, we're not going to do that. You can fix the error and get it right. But every binding in HTML is automatically sanitized. That means that Angular look at your data and says, well, I know these features are good, like the bold. That's fine. The image tag. That's pretty cool. Harmless. I'm going to allow that. Error attributes. I don't know what that means. I'm going to take it out. If I don't know it, it's probably not safe. I'm going to take it out and make sure you don't up with a process in your application. You are protected against process scripting as an Angular develop developer. That's awesome. The good news of the story is first of all you need to get out of the way. Just let Angular do whatever it does. Angular is good at that. Just do things the Angular way. Don't try to be smarter than Angular. Do whatever Angular says, put this into the DOM. And you're good to go. This applies everywhere. And apply to href, give it this, guess what the browser does? JavaScript. Oh, just like that. However, if you try to do it as an Angular, Angular is like, no, no, no. I know this is in the field. JavaScript is knowing it's dangerous. It's not safe, it doesn't recognize it. I'm not allowing that value in that URL. That is really pretty awesome. By the way, as a side note, Angular is the only framework that does this by default. Other libraries like React, Ember, they don't offer features like that. URLs are not protected there. You have to do that yourself as a developer. You don't do sanitization either. You have to do it yourself. Not necessarily that hard to do it. But you have to do it yourself or offer libraries that offer this. Angular does this automatically. That's why I'm personally a big fan of Angular here. The second is don't use functions that start with bypass security in the name. You can manage that, right? Why the bypassSecurity? In Angular 1, it was trust as HTML. You will find code snippets on StackOverflow that we use to build our applications that misuse that function and as an unknowing developer, you didn't know unless you picked it up on your own or watched one of my talks. That's why they renamed this to bypassSecurity. If you go from StackOverflow, and it says bypassSecurity, that will make you think, what does that mean? That will trigger looking up the documentation. If you're building libraries, by the way, you offer unsafe functions, always put something like that in the name. It works well to trigger developers to notice it. How does this work? Well, if you feed that untrusted data and you pass it through the function, Angular is not going to protect you. In this example, giving it the data from before will actually give you that pop-up. Because the function bypassSecurity can tell Angular, this snippet is safe. I vouch for the safety of this snippet. Angular is like, oh, in that case, I'm not going to do anything. Go ahead. In this case, it ends up in that location. This is intended for static code snippets. If you want to output the static code snippet, something you wrote yourself. Sure, you can use this. But don't ever use this for untrusted data. Outputs should never pass through this function. Third guideline, don't use rob DOM API. There are ways to get access through relevant revs. Don't use them to output data into the DOM. Don't set attributes or content with those values because Angular is not in the loop anymore. The minute you get the element, and start calling APIs, Angular cannot protect you. And outside of Angular with jQuery, that's bad idea. A lot of internal knowledge to prevent processes. They do a lot of crazy things. So, don't do that. Stick to the Angular way. Very important guideline. And final guideline, to road cross-hat scripting here, don't give users control over resource URLs. They are the only place you need to think about security yourself because Angular cannot. Let me give you an example of a resource. Dynamicically loading an iFrame. You see here this value will automatically trigger the loading of a document when you set it. There's no clicking in between, nothing in between that triggers that loading. So, Angular, if you give it a URL like this, it will load a YouTube video. Very easy, very straightforward. However, if you give it data like that, it's going to pop up an alert. I know. Why on Earth can you put a JavaScript in an iFrame to pop up, I don't know why. But it works. Challenge here is that Angular can't really protect you. Yes, they could determine that you probably don't want to do this. Probably. Shouldn't. But do you want to load a YouTube video? Maybe you do, maybe you don't. You want to load stuff. What if this value comes from user and says HTML, you want to load that? Probably not. But I don't know. Maybe. So, Angular can't really decide that. Angular doesn't know what to do here. It's going to give you an error by default. No, no, no. I know you want to set this. But I don't know whether to tell you it's safe or not. Please tell me it's safe, and then I'll put it. That's essentially how this message translates. That means that you have to write some code. You have to write a function or a way to tell Angular, hey, this URL is okay. Resource, trust this URL with this URL. Of course, before you call it, you better make damn sure that it's trusted. Ensure it's a safe URL. The recommendation here is never give the user full control over that URL. Because the moment you do that, it's gonna be tricky. Secure, ensure it's safe. So, if you fix the scheme, the host and at least the thought separator, and then you fix the host where the request is going to, that way you are entirely sure this request is going to YouTube. And give the user control over the untrusted part, the identifier, you merge that into the URL and you're good to go. Then my recommendation here is that you spend some debt mechanism. Run it through the default URL site. With Angular users, hrefs and an Angular tag, use that to ensure that if something crazy happens, Angular is in the loop. No, no, this is not safe, so, I'm not going to allow that URL. You can ensure that the resource URL is safe and put it into the page and Angular will load it. Awesome. Final word on this. Use AOT. It's going to be in development mode automatically from the next version. We heard in the keynote this morning. Definitely recommended. It prevents weird templates from Angular 1. And there's no combination of -- I'm not going into detail here. Just use it. There's a lot of benefits. And one of them is security. That brings me to the first statement. That is a message I have been teaching a lot of developers in training when we talk about Angular. We talk about multiple frameworks, but Angular is easier. A bit messier for other frameworks. Automatically applies. Just follow the Angular way of doing it. Don't try to fight it or bypass it, just do things that Angular expects and you're good. All right. One down. The next stoppic is called broken authentication. Which is a very generic way of saying everything that has to do with users and session management kind of thing is messy and problematic. Yeah, there's a lot of vulnerabilities. I'm going to be fairly brief here. I'm going to sketch the landscape and give you some advice and point you to further resources to look at after this. So, we're mainly dealing with user authentication. And authentication, beall know pass words, but you know them. And our users know them. Authentication landscape has gotten really complex. You have attacks like brute forcing, attacks like credential stuffing where you take leaked credentials from other websites and try them out against your application. You have time-based attacks. All of these are insanely complicated to stop. Password policies and account registration, account recovery and all of that is a lot of effort to build. On top that have, you have multi-factor authentication. And you have awesome things and that means you have to implement that in your application. All of that I can guarantee you, don't do that in a couple days. A month effort. But even then it's going to be really hard to get that site secure. My recommendation today is, don't do it. Don't build it. But you need some security. so, don't throw it all overboard. Offload that to a provider. Use something like OpenID connect that allows you have your Angular application on an identity provider. And they are responsible for handling all of that. You just log in with Google. Awesome. Google is responsible for handling all of that. You call them and get some resulting back and you're good to go. Of course, you don't have to do this with a public identity provider. You can easily use them as well. You can buy one and have open source solutions and cloud-based services that you can use that are private to your application. There's a lot of options here and it's really, really recommended to go that route. Just implementing all of that. You don't want to be spending your time on that anymore. If you're using oidc in combination, itle be with it. And figuring out how to use OAuth and oidc. I'm not going to talk about that. There's a session after mine about authentication in Angular. I don't know what's going to be covered. Because I'm going to be in the audience as well. But it's probably highly recommended. They should know what they're talking about. And I just to want set a few things straight about OAuth and oidc. What you have here is you have the user that's authenticating to the identity provider. Log in with Google or your system, it doesn't matter. It's only authenticating in one place and one place only. Building an Angular app, the user is intacting with the app. If it's frontend-only, no backend, Google APIs, whatever, your app is going to be receiving. They're authenticating to the front. Don't really authenticate at the frontend, and they know the risks and the users and they can identify. Then the frontend can access a couple APIs and do that with OAuth-based. So, OpenID connect is about authenticating an application. And o auth is accessing APIs for the user. These are merged together, but different concepts. Don't use identity token to access API. There's enough incentive to do that. Use OAuth action that you can get the tokens during the flow. For example, for Google, build an Angular frontend to manage some Google spreadsheet data, for example. And use it to log in with Google. Ask permission to access spreadsheet and you get an access and identity token. And you can access the spreadsheet with the token. It's one way. Another way would be if you have your own backend. If you have your own backend application, your Angular app is, again, what the user will interface with. And the Angular app is going to interface with your own backend. In that case, the user is working with the backend. They are going to the identity provider. Log in with the identity provider. And your backend will know, oh, user authenticated user ID something, something. The backend will link that to an internal messaging form. This user on the form is actually, dolphins are great. Now we know that dolphins are great authenticated and we can link that to the data we have internally. Again, the identity is used here to authenticate against the backend application. And the backend can access APIs for the user if they want to. These are two very different use cases. They require the use of different flows. But if you have more questions about that, I would be happy to talk about that later in the expert room after lunch. Broken authentication recommendations. They always give developers at most companies have and moving in the direction is using OpenID Connect. You don't to want implementing it yourself. For accessing on behalf of the users, use OAuth2, that's what it's designed for. It's awesome. You don't have to implement the dirty details yourself, there's libraries available that support all of these features. Use them and I highly recommend them. I gave you one example on the slides before. And you can find many more online. By the way, if you want to grab a copy of the slides later, they're available on my Twitter feed. You can find the link and grab them from there. All right. One more. The last one is about using vulnerable components in your application. Especially in Angular it's a real problem. Because over 97% of applications are dependent -- of application code -- are dependent on it. 97% of your code or your application is code you are pulling in from the Internet. And I know that 97% is like, that seems like a lot. How much is it really? Oh, I run the numbers a while ago. If you generate a new clean Angular application that command is going to ask you some yeses. Like, you want routing? Yes. Sure. We want to do some SaaS or whatever. Yeah, that sounds good. Yeah. It's gonna run NPM install in the background. It's going it take a while. It's going to come back and say we installed 1036 from 1030 contributors. Yeah. You're now running code from a thousand developers. Impressive. But how much is that really? Oh, let's count the lines of code. There's an NPM module. Count the lines of code. You install the NPM module. And you can start the lines of code. You'll find a lot of languages in there. The interesting part is you'll find that they're now including 2336228 lines of code. This is a real number. Building a new Angular app. We have written zero lines of code. Yet our application is 2,336, 228 lines of code. That's what we're talking about here. That's a lot of code. That's a lot of code you're trusting on. If not, you're vulnerable. This is built by developers. A lot of them are volunteer developers, freelancers. They're doing this out of the good of their heart. And they all make mistakes. We all make mistakes. So, one of these mistakes can be a scripting vulnerability. One of these mistakes can be god knows what. That can happen. So, what if that happens in one of these dependencies? Then it's a problem for that library. They can update that. But now you program, your application is also vulnerability if you have that dependency you will need to update that. This is something that will go on and go on. and that's only about legitimate mistakes. This ecosystem is under a lot of attack lately. This is a very lucrative attack. Let me tell you one example story. Not necessarily an Angular story. It could be the React system. Doesn't matter. It can happen to anyone. Let me explain to you what happened. There's a company called Komodo, I think. They build a problem to manage your cryptocurrency in a wallet. Very, very sensitive. It's real money. Depends on what day it is how much money. But you kind of get the idea. And the attacker in this case, it was an open source application. Hey, wouldn't it be cool if the application was an electron running on the desktop. And use Mac OS applications. That would be cool, right? The product owners were like, yeah, that would be cool. You want to get a pull request? The attacker went to work, created a package, Electron-notify-native. It hooks from the system and published it in NPM and they added a pull request and added it to the application. And two days later, that was included in the target application. Two two weeks time, wouldn't this be cool? Here's a pull request in your application. Everyone was happy. It was a legitimate feature added by a volunteer. Awesome. That's what makes the community beautiful, right? That's what we all depend on and what we hope is going to happen. Then we have to now include my dependency. And they updated to increase malicious code. Now it's going to do this notification. Sure. A little bit extra was not good extra. It included code to steal from the wallets and publish on the server and build up a database and get access to all of these wallets at the same time. A couple weeks later, the target application, the wallet system in this case, included that dependency. But at that moment the malicious code started running, collecting the seeds and publishing them on the server and waiting to grab all the money. This is bad. This is a targeted attack against -- there's a plot. The good part is NPM tries to do as much as they can and they actively scan libraries for patterns to detect that. And they detected this and they said, uh-oh, this is not good and contacted the company and said, we have a problem. Because the seeds were already stolen, the wallets were already accessible by the attacker if they decided to do it. And they decided what to do with that? And they stole everybody's money using that vulnerability, put it in a safe location. They transferred all the money to a safe location, and set up a whole process for users to reclaim their wallets through the proper procedures and get access to their money again. This is to show you what we have to deal with today. Any of these dependencies in your application can become malicious at any time. Whether it's intentional or because of a mistake or someone breaking into NPM into that specific account and publishing an update. All of that can happen. We need to be aware. There's not much we can do against these active attacks. There are a few things you can do your applications. And you should set up dependency scanning today. Because there's a lot of known vulnerabilities. We know that version X of in library is vulnerable to this effect. If you haven't updated, you might be vulnerable. GitHub has a free service. Dependency graph, they scan with JSON or whatever you're userring and say, these libraries are vulnerable. Update now. And a similar tool, dependency check, can run in offline mode, supports different languages. Awesome software. Scan against known vulnerabilitieses and they tell you about that. And Snyk is a commercial company. They have a lot of good features and offer a free version for open source developers. You need to be aware of this. Set up dependency scanning. It's really, really, really important that you do so. And you can update your library as soon as possible. That brings us back to the beginning. We talked about the top three. There's seven more if you want to collect them all. Some people like that. Talk to me at the expert zone. I will be happy to go into depth with all of these. To wrap it up, I built an Angular security cheat sheet which you can grab from my website. Go there or Twitter, you will find that link. A nice overview of things to watch out for in an Angular application. And with that, I have zero time left so I'm gonna wrap it up. And I'm gonna thank you for being here. Follow me on Twitter for more security news and talk to me at the conference while I'm around. [ Applause ] >> Thank you very much, Philippe. There's lots for us to look at. And like Philippe said, you can catch him in the expert zone later this afternoon. And next we have the angular app by Manu Murthy. And you can find out more about Manu's journey on the Angular team. Thank you very much. . . . . . . . . . My journey on the Angular Team Manu Murthy >> Hi, and welcome back. So, up next we've got Manu who is going to talk to us about his journey on the angular team. Let's hear it for Manu. Thank you. MANU: Hey, folks. I'm Manu Murthy. I manage technology programs and help organizations realize their strategic goals. Today I'm gonna share with you some real stories from my journey on the Angular team. Experiences and lessons live learned that you can apply to your own projects. By way of a quick introduction, I'm a program management leader. I joined Google and the Angular team in October 2017. Prior to that, I led large programs at Apple, Hewlett Packard. I'm passionate about web development in general and agile methods. Outside work, I'm a landscape photographer and enjoy Travelling to different places and capturing stunning landscapes. Before I talk about my journey, I would like to take a few minutes and describe why I joined the Angular team. One of the main reasons I joined the Angular team is the value system that Angular upholds. The team truly cares about building an inclusive environment, regardless of where you're from or who you are. Respect for each other. Making everybody feel welcome to contribute and perform their best. And this is the core value system of Angular and it makes me proud to be part of that culture. Angular is also a complete framework. The use cases that are important to building web applications I have been taught end to end-from animations to native experiences to serverside rendering. With Angular, you can leverage those proven time-tested patterns and use them in your own apps. Angular is also life-changing. People choose and see Angular as a -- for themselves. And I was talking to a gentleman yesterday. He said he speaks three languages, Hindi, his mother language from India, English and Angular. And another person told me, and I quote, your team creates what I use. Unquote. And having that kind of profound impact on people's lives is truly amazing. Angular also has an active and vibrant community and support system. You have a question that a lot of places you can turn to for help. StackOverflow. There's several online forums supported with Angular. And last but not least, the super-awesome team that I have the pleasure of working with every single day. These are some random pictures that I captured with these amazing people. This is a picture from a pizza movie social we had a few weeks ago. The Angular team works really hard and we also play hard. I also wanted to paint a timeline of my journey this far. I have worked on three major releases, version 6, 7 and 8. And looking forward to version 9. I have worked on minor releases and patch releases. And the experiences I will be sharing today are from this time period. All right. Let's jump right in. Story number one. Keeping up with the ecosystem. The world does not stop. The ecosystem is constantly evolving. And that creates with the need to plan for change. There are key dependencies that we update for you with every release of Angular such as TypeScript, RxJS, zonejs. These are dependencies in your package JSON. For example doing an ngUpdate will update the Angular packages and run schematics to keep you up to date. Let me quote an example from version 6. RxJS release prior to version 6. It was a very significant release with a lot of major changes that we had to integrate with. We also automatically had the package, ngApplication as part of the update to make the introduction of RxJS smoother. While all of this eventually came to fruition, the scope of RxJS and the user experience was unclear until very late in the project. Also, RxJS-compact took several iterations to build, and then we had to estimate it. And the Angular team underestimated this seemingly straightforward effort. And it put a lot of pressure on the Angular version 6 for the effort. Another example of keeping up with the ecosystem. We were faced with a CLA memory issue from version 8. We had moved from node 10 over to node 12 in version 8. And following that, we got reports from users that projects they were building in the past are now hitting the memory limit. And in some cases the memory usage went up by 70%. We worked with the VA team. So, the VA team is Google's open source JavaScript engine team, used for Chrome, Node.js and so on. And we worked with the Node teams to get to the bottom of the issue. The team built an instrumented version of v8 with a custom version to get to the issue. We were able to isolate the issue and the AOT compiler. We were copying from a prototype while cloning objects. The practice was optimized in older versions. But with the new v8, this was no longer supported. And so, we had a problem. The fix eventually came down to a one-line change. And we were able to get the performance back to where HTTP, but it actually took us a long time to get there. All right. So, what are some of the key lessons that we can take away from this experience? Think through your dependencies across your ecosystem and actually document them. Plan time in your projects to actually deal with and update those differences. 5-10% of the time. If you have a more complex integration, obviously you want to factor in more time. And this is something we do across the board at Google because we have a monorepository and we move together as a single unit. Also, try to front load your plans. And that way it will give you time to react to any unexpected findings that come up. I also talked about documenting dependencies just a moment ago. And here's an example of a dependency matrix that we developed for Angular. You see the three main repositories, components and tooling and the different dependency items. We actually created this in version 6. And we started using this for subsequent releases of Angular. It helps us understand the scope of the work, track it and keep it. Story number two, does how you do stuff matter? So, process is an area which is near and dear to my heart. Process describes how things are done and provides the focus for making things better. In late 2017, there was a lack of process focus in the Angular team. The processes we had were not scalable enough to meet Angular's ongoing, you know, growth. And it was also really hard to answer simple questions such as: Are you on track or off track on a given day? What's the level of risk of your project? Are people working on the right set of priorities? So, fundamental questions were actually really hard to answer. One of the biggest lessons my team and I learned is the reality of project plans. The plan is really your best guess of how you think the project will proceed, as the top part shows. And in reality, it's quite different as the bottom shows. We wanted to build a process that helps build a plan that is applicable. So, we started on the process transformation journey. And we wanted to stay focused on a few things as we did that. Things that truly impact the end user's satisfaction. Things that executed often, think of it as the 20%, the things are executed 80% of the time. We wanted to focus on those things. We wanted to make sure they were measurable. And most important, we wanted the process to be -- scalable. And this is the transformation that happened between late 2017 and today. So, previously we had a mixed hybrid model of waterfall as well as what I call scrumfall. We had very basic project management tools, spreadsheets as well as documentation. There was a lack of execution metrics. Things that you can use to assist with your projects. And there was also lack of regular, you know, enmetrospection retrospectives. And triage for technical debt was happening on a long basis. And we now use Kanban and Scrum. We have a model. And some of the areas that are evolving rapidly that you can freeze within the scope of a sprint. We use Kanban. And other places where you can actually fix for a week or two, Scrum. We use Jira. We use graph projects. We are tracking metrics such as velocity, blockers. But we're not really using them to drive the decision making. But something I would like to do in the future. But we have them. We also have a regular cadence for monthly sub-team retrospectives. We do twice a week triaging of bugs. I will talk about that later. We also have a scrum of scrums. Where the function leads from each of the areas get together and we talk about interdependencies and really anything that's cross-connected. And we do tech teams, tech talks, excuse me. All right. We also have a set of guiding key performance indicators that we use to understand the health of Angular as a product. This is not an exhaustive list. But some of the things we look at is the hello world bundle sites. We look at the traffic for our docs website. We look at analytics for CLI often. We look at integration time for the PRs, the requests. And run benchmarks for build and runtime performance. At the end of the day, methodologyies is a way to think, it's not a substitute. There isn't a silver bullet. The important thing is to understand the key questions you and your stakeholders are thinking about in the program and develop a methodology that actually helps you with that. Story three: Own debt before it owns you. Debt is a very important consideration. But unfortunately it's also the most forgotten one. And we on the Angular team are quality of the same. So, debt can probably be classified into technical debt as well as bud debt. You might have a different definition of technical and bug debt. For the purposes of this conversation, let's define technical debt are what you infer. Shortcuts with the cold, decisions you make, band aids you put in. Bug debt on the other hand is deficiencies and deviations that happen. Okay? It's actually less important what you call it. The more important thing is how you prioritize and deal with it. Best time to plant a tree is 20 years ago, and the second best time is now. In the context of the conversation today, that mean it is you want growth in the future, the best time to act on debt is right now. So, what are some of the lessons we learned along the journey, right? So, accruing debt is bad. Not paying it down is worse. Because if you fail to pay your debt down, then you actually, you're paying the interest on the debt every time you track the code. Try to allocate 5-10% of your project time to tackle this. It's hard. Trust me. And it's an area me and my team are trying to do a better job at. And I will continue to push for debt management in my role as program manager for Angular. Here is a bug triage process we actually use on the Angular team. Triage is how you characterize and prioritize the issue to focus on what is important. The issues go through two levels of triage. We basically identify the functional issues and then we also identify the seriousness of the issue. Once triaged, we are able to see the overall priorities on this home grown dashboard that you have developed. This helps us prioritize the work and relationship with all the other pieces of work that we have. This is not a prescriptive solution. This is just how we do it on the Angular team. There is a lot of scope and improvement ands that constantly evolving. The key takeaway here is that have a process, and act on the process often. Story four: What the smoosh happened happened? So, there's a proposal for the GS language feature which is a prototype which turns out to be web incompatible. And specifically, there was a modals library being used by seven websites. And the proposal author jokingly suggested renaming flatten to smoosh to tackle the problem. The joke wasn't clear to everyone, and things escalated pretty quickly. So, my good friends in RxJS took this opportunity to create from the joke. By converting all the merge operators to their smoosh counterparts. They then pushed out RxJS, smoosh.0 on NPM. And a message popped up. Since you published this on NPM, and it resolves the smoosh, you're now breaking it. I recommend that you unsmoosh it by publishing smoosh that removes the breaking change. The issue was fixed. But the key lesson here is that consider the impact and consequences. Seemingly harmless stuff like this can have a negative impact. And sometimes the impact is reputation impacting. We're also exploring different continuous integration to alleviate the stress that we have. Story number five: Infrastructure as an after thought. In the past, Dev infrastructure on the Angular team was everybody's problem. So, in effect, it was nobody's problem. So, there was a lack of accountability. And the team didn't fully understand or appreciate the impact and complexity of Dev in general. We also had a lot of flakiness within infrastructure. And we were patching those things or we were band aiding those things to solve the moment's problem rather than systemically fixing it. And what that is, it increases the amount of debt you have. And this is not just to Angular, but also the entire community. It affects everybody trying the API. We embarked on this Dev infrastructure effort. We nominated a sub lead and a team. And the things that we wanted to fix. Here is some of the recent work on the Dev infrastructure front that we have been doing. Now, my team will be talking about these things in more detail, he's got a talk coming up. And I think it's titled GitHub at scale. If you want more information about these things, I suggest you go to the talk. But in terms of what we have implemented, we have done remote execution to work on the builds. And this improves the speed and cost efficiency for us. We also take care of caching. Louse us to do this and gives us the incrementalty. And we have established several benchmarks and tracking for local rebuilds, integration tests, response time and so on. And we have put a lot of emphasis on Windows CI. Story six: Finding leaders. As Angular grew, we had to reorganize ourselves to be able to scale better to the needs of the -- to the growing needs of the community. We also needed a better system of accountability. And we also wanted to align with the process transformation work that I was alluding to earlier. We created various sub-teams and assigned technical leads. This helped to provide the focus and particularly helped us manage interdependencies across these subsystems better. This is how Angular is organized. The top portion of the pyramid, we have the Angular Google team. We have just talked about the sub-teams and performed and how we organize Angular on that front. The bottom part of this triangle is the user base and the community. And as Angular is a very active community, this is growing faster -- much faster -- than the top of the pyramid. So, how do you keep up with that if had and how do you scale to meet the growing demand? This is where the middle section of the pyramid comes. And you're talking about community collaborators and enterprise collaborators. These are people who have demonstrated high quality work and code, documentation, helping others in the community, filing an awesome bug report. They are all valid forms of contributions. These folks have a mentor assigned on the team. And they have the formal support to make contributions to Angular. So, these are the eight amazing people we onboarded recently as community collaborators. And these folks have made incredible contributions to Angular. We have actually been very fortunate to find them and work closely with them. And these community leaders help us scale Angular better. In addition, we also have an amazing Google expert developers program. We have about 105 GDEs, leaders. And we also established an early access program which is used for them to actually validate the releases before they actually release the customer. So, that's another level of quality check that we put in. In summer 2019 we had three amazing interns work on the Angular team as well, Alyssa, Elana and Ayiz. And we have hundreds of requests from the community. And one of the interns built a process to manage the pull requests more efficiently. This will ensure that important issues from the community will not fall through the cracks. Ayaz is also one of our interns and built a tool that sens through the Angular code and allows you to get access to semantic information from the applications. This is built on language. And Elana, also doing a talk at Angular Connect today. And she built a tool for searching for tools and libraries in the ecosystem. The results are curated and you can see merited information such as bundle size, any accessibility, and the presence of Angular-specific tools such as ng compatibility. All right. In summary, plan to keep up with the ecosystem. Have a process, you know, measure and continuously improve upon it. And how you do stuff actually matters. Burn down your debt. And allocate the time to start doing that now. Always consider the impact and consequences of stuff you do. Pay attention to infrastructure, plan infrastructure. Do not let it be an after thought. And lastly, find leaders. Get out there. We just need to find them. I'll be posting the slides on my Twitter account. Thank you for joining me on this journey and have a wonderful rest of your conference. [ Applause ] >> Thanks very much, Manu. That was really interesting. Getting an insight into the Angular team. So, up next, community lunch. So, we have the community lunch starting now. Which is about roughly on time. So, it will be lasting the full hour of lunchtime. So, you can go down to the mini workshop room and grab your lunch there and join other community members to network and discuss about community stuff. For those that are just having lunch, lunch is available both on this floor and down stairs. My clicker -- so, lunch is an hour and we'll see you after that. Thanks very much. . . . . . . . . . . Next up after lunch: Sponsor talk: Progress . . . . . . . . >> Hello, everybody. Hey! Where are you? I can't see you. Okay. Oh, hi. I'm your host for the following sessions. And I'm really happy to be here. How about you? Yeah! How was lunch? It was good? It was tasty, right? It was good. Oh, the desserts, oh, my god. And so, I hope you also enjoyed lunch. And enjoyed the conference so far. Right? And I hope you're going -- we're going to have a fantastic afternoon. And let's start. So, first thing that we're gonna do now is the Slido. Who has heard about Slido this morning? Okay. Great. So, we're going to do a quick question now. Which country are you from? So, you just log into Slido. com and enter the code AngularConnect. And we want to see which country you're from. And we're doing this also in the other session. And we're gonna see the result slides in a few seconds. Wow. Look at that. So, a lot of you are from the United Kingdom. But it seem like more from Germany. Could it be? Yeah? Who is here from Germany? Okay. Yeah. And who is from London? Yeah! Where else? What else do we see here? The Netherlands, Austria. What's the furthest place that you can see here? Where? The moon? Is there the moon? Mars. Wow. Oh, my god. That's so great. And we have -- okay. Almost 400 people have answered it. And keep answering. Great. So, we've got a good dataset here. Great. We can work with that. All right. And now the next thing that we're doing, you're gonna submit your questions in Slido. Yeah. Yeah. So, now if you've already opened Slido, right? So, think about a question that you want to ask the panel tomorrow afternoon. Right? That's what you're doing now. Awesome. And next we have a great sponsor that's sponsoring this wonderful, wonderful conference. Progress. Is there anyone here who hasn't heard about Progress? Yeah. So, everybody knows Progress. But Carl Bergenham. Where are you, Carl? You're gonna talk about Progress and tell us what's new there. Thank you. Give a hand. [ Applause ] Carl. CARL: All right. Hey, everybody. Let me wake up my laptop here. And as I type in my password incorrectly in front of everybody multiple times, this is going to be a great deal of embarrassment. There we go. My name is Carl berk and I'm the product manager for Kendo UI. You might have talked to me. I see familiar faces as I'm scanning through the room. The reason we're here is because of Kendo UI Angular, built from the ground up specifically for Angular. And I wanted to just quickly open up our demo page to give an idea what I'm talking about when I refer to UI components. And really you can see a lot of it here where we're covering everything you might need for more advanced components, data grid, scheduler components similar to you might find in Google Calendar, charts, graphs, gauges, all that good stuff. And the more basic elements like buttons, input elements and maybe drop down pickers. All that stuff. All contained within one single library. We tend to say we're not opinionated. In terms of design languages, maybe a good example is going over the button real quick. We integrate with multiple design languages. We have our own design language out of the box. We have a material theme that you can see right here. And then in this resolution, let me see if I can open up the bootstrap theme. We also have the bootstrap theme available out of the box. With these three, rather than forcing you to go with our design language, you can integrate with our favorite one. Using Angular today and you need to augment with our components, you can easily do so with drapping them on the page. Line up the SaaS variables and line them up. Just some quick examples. We have our grid, which provides a lot of the functionality that you need out of the grid out of the box. So, we have paging, sorting, filtering, grouping. I could, for example, drag by this column header and create some quick groups for us. Multi-group headers, a ton of interactivity and a focus on performance. We do visualization across the board. Column and row visualization within the grid for heavy data entry. And the same thing within our dropdowns and a couple other components. Another component I can shout about is our scheduler component, which is similar to what you are dealing with in Outlook or Google Calendar. You can have an all-day event that stays there as I scroll through. And we can double check on an element and see a pop-up up here unless I messed something up with the demo. That provides you to do reoccurrence editing and editing your information. And we have the ability to go into a timeline view or an agenda view where you can set up different resources and have it be arranged by those particular resources. Whether those are people or rooms or whatever it might be. And then just quickly also wanted to show off our rich text editor which is, of course, exciting. You can do a ton of good stuff like you might, for example, do in Word and inject in your applications. Get your users out of Word, Excel, all these applications and shove them into your applications instead. So, if you are interested in talking a little bit more. I have myself and some of my engineers by the Progress booth right outside. I want to mention that everything you see is free and fully functional to try out. We have a 30-day trial to give you access to not only the components which you have access to as long as you need to, but also access to the support ticketing system and you can chat live with our developers if you need any help or anything like that. I believe that's all of my time. Thank you very much and I appreciate it. And enjoy the rest of the conference. [ Applause ] >> Thank you, Carl. And thank you, Progress, again. So, our next talk. The speakers are two good friends of mine. And they're both very involved in the Angular community. Uri Shaked is a -- he -- well, he regularly writes a blog post. A lot about Angular and also other things like IoT. I remember that he had a challenge a year ago about writing a blog post once a day. Is that right, Uri? Are you still doing that? Okay. Okay. It's -- yeah. It's a great challenge. And among other things, I have my notes. Yay! And he's -- he's also interested in all -- in some of the -- some other technologyies like virtual and augmented reality. And hardware hacking. And neuroscience, building 3D-printed robots, and games. Playing music. And is there something that you don't do? Don't go -- but you don't go to the gym. But you do dance salsa, right? Uh-huh. Yeah. Okay. And Dominic. Dominic Elm. He's a trainer at thoughtram. He teaches Angular and he's a software developer. And he's also working on some really interesting open source projects. I have them written here. Angular Tech List which is a curated list of best practices for your application. And he's a co-creator also of ngTemplatestrings, bringing more to Angular templates. And enjoys hiking and biking and of other stuff in his free time. Do you have free time, Dominic? No. No more than that. Okay. So, for the next talk I'm so happy to invite you to. Give a hand to Dominic Elm and Uri Shaked. [ Applause ] >> So, hello. Thank you. Do you see my screen? No. That's -- whoo. Now you see my screen. It's alive. What's alive? We're alive, I guess? >> We're alive. >> From the stage. In >> Great times, hopefully machine learning can write code for us. As you will discover soon. She did some spoilers. So, we won't go over this again. But Dominic and I met here in AngularConnect last year. We attended a very interesting talk. Do you recognize this guy? URI: I think I recognize him. If I look closely, I think his name is aseem. That's at AngularConnect last year, almost one year ago. And it looks like, I don't know, you probably know him from some of the projects he did. Can you remember what that project was about? DOMINIC: Yeah. He showed a lot of exciting demos with machine learning. One was taking a photo and running it to an algorithm that will tell you what the emotion conveyed in that photo is. And then replacing that photo in the present state with a modifier. Worked quite well. DOMINIC: Yeah, it worked well. URI: And he had another interesting concept. DOMINIC: Yeah. He talked about AI in JavaScript and a couple examples. One that we remember well was this form. The goal was an HTML form by putting in a description of that form so we could say, hey, we want to have an input field and two check boxes and a a radio button and all these things. And automatically it will generate that form for us. Isn't that insane? But guess what happened next? URI: He released it as open source? DOMINIC: Not quite. I don't know. URI: Click the submit button and then you can load it. ♫ ♫ he fooled everybody. So, I guess we're not here for dancing. DOMINIC: This song is called Never Gonna Give You Up. We're not going to give up on that. It's not possible. URI: Thank you to As im for inspiring us to do this talk. DOMINIC: We wouldn't be on this stage. We had a lot of inspiration from As im. URI: After the talk, we started brainstorming, how could we bring this into reality? What could we do? We had a couple of ideas like sketching an app on a notebook and scanning it and getting it out of that. But eventually we had one idea that clicked. DOMINIC: Exactly. We went with this idea of automatically generating code for us. Basically taking away our job. That's our job, writing code, right? So, what we thought was given a function signature, that's what we see there, we pass it into this black box that we call model. And then we wanted to take the implementation of this function. And in this case, it's just adding A and B together. That's what we wanted it to do. URI: So, basically given the start of the function, write a function. DOMINIC: Yeah. URI: And what's the thing in the middle? The model? Can you explain a bit? DOMINIC: This model, we don't have to dive into all the details. But think of the model, this black box, as a JavaScript-ish function that has one input. That could be anything. We pass in an input, it does computational magic. We don't have to worry about the magic. And then returns an output. That's what model does. URI: Basically it's magic. DOMINIC: It is, but we don't have to do this computational magic ourselves. We let the machine do the function. URI: That's what machine learning is all about. Getting the content of that magic model function figured out. DOMINIC: Exactly. URI: All right. So, speaking of magic, can you hold this for me? DOMINIC: I can. I don't know what's going to happen. URI: That's machine learning. It doesn't work. DOMINIC: Machine learning doesn't work. URI: Try that again. It's broke. We will try that again later. DOMINIC: You might be like this, we've just seen that generating an HTML form from description is not really possible. You might be like, oh, come on. Stop fooling us, it's not possible. But... URI: We actually went ahead and tried this and gave a talk about it a few months ago in a great conference. And you will will available to see in a moment what it looked like in that talk. We tried to right. DOMINIC: That's a glimpse. Let's have a look. Hopefully the audio works. URI: Yeah. You were really surprised by the implementation. Like, I wouldn't say it's the most straightforward implementation you would come up with. DOMINIC: Well, I can see flush after. It kind of subtracts A from B. It could be -- I think setting the thing -- it's very creative, I would say. URI: But, yeah. The model got really creative. It did manage to create like valid code which is quite amazing. And very creative indeed. And after this talk, we were excited. And we summarized our learning. So, first of all, as you probably have -- you just had a claim spot, we learned that automatic code generation is hard, right? DOMINIC: Right. We also learned that data processing -- we talked about this a lot at NUviking. Data processing, cleaning and gathering the data, all those things, that makes up a huge chunk of the work. It is a lot of the percentage of the type of work just focusing on the data because the data is so important for machine learning. URI: And basically we really love working with machine learning. We found it hard, difficult, but fascinating. And we decided to give it another go. This time we had a different goal, though. We decided to think, what else can we do with code? DOMINIC: I could think of a couple of things. But let's not try to take away our job. Let's try and create this synergy between us and machines. URI: I have an idea. Do you like to write comments? Do you write comments? Do you people write comments? DOMINIC: I have to. URI: Who writes comments? DOMINIC: Who likes to write comments? URI: who likes to write comments? DOMINIC: There's someone. That's good for you. URI: Wow. You can come and work with our machine learning model together. For the rest of us, we decided to try to, again, given a function, this time the entire function, just predict what the comment would be. Have this model function. Return us the comment for that function. DOMINIC: That is great. I mean, that really makes our lives at developers much easier. We don't have to document our code. We just have this model which generates the comments for us and summarizes the code. That is fantastic. Does it work? URI: So, we also had another goal. Before we show you if it worked, we decided this time we were going to use machine learning with JavaScript. Because traditionally machine learning is done in other languages such as Python. And then if you want to take your machine learning models and use them everywhere, basically on the web or in Node. js, it's not very straightforward if they are written in Python. Python doesn't run on the web. So, we decided to try and use JavaScript this time. We'll tell you about it in a bit. So, the process -- the general process looks like this. We start by gathering data. DOMINIC: We need a lot of data. URI: Like a lot. Like how much? DOMINIC: Well, maybe 300,000 of examples? Or even a million of examples. So, it's a lot of data. URI: And then I see we need to clean it and prepare it. DOMINIC: Yes. URI: So, it's easy for the model to find out how to approach code. Like, and then we need to train the model. DOMINIC: Exactly. But this is basically what we've talked about already at ngVikings. But as we know, we wanted to add this layer of JavaScript to it to make it a little bit more practical for us so we could consume. What we did is we added another layer to this. So, taking a trained model, we're gonna see what it looks like. And then somehow use TensorFlow JS to consume it in JavaScript. URI: So, TensorFlow, that is a machine learning library for Python. But it has a special property. There are also versions for JavaScript, for Android, for iOS. So, a bit like Angular. It's universal. You can run your models anywhere. You can create them in Python, run them in JavaScript. DOMINIC: Exactly. And then once we have it in the JavaScript world, we can then use the tool that is we use, such as Visual Studio Code, which is awesome. And then we can create an extension for it so that we can consume the model in an extension and then predict the comment. URI: All right. So, let's start with gathering the data. We need -- you said like -- DOMINIC: A lot of it. URI: A lot of comments. So, we have like 500 people in the audience. If everybody writes comments for us, how long will it take us -- do you perhaps have a better idea how can we get a lot of comments? GitHub! Yeah. So, yeah. Can you go in GitHub and just download... DOMINIC: Well, I know what I typically do. Press this button. Go through all the repositories and click the down-up button. URI: Hundreds of thousands of times. DOMINIC: It's gonna take me a while. But, sure. URI: I have a better way. Let me show you. So, there is this thing called BigQuery. It's large-scale data warehouse from Google with a lot of buzzwords in the name. But basically what it means, it can run SQL queries on an enormous amount of data in a matter of seconds. DOMINIC: Can you show me what that looks like? URI: Yes. It also happens that BigQuery has the entire open source code from GitHub as a dataset that we can query. And let me take you to my laptop where I can show you BigQuery in action. Spoiler: Another spoiler. Yeah. So, this is basically BigQuery. And I have a query here. I'm going to run it in a moment. You can see it's going to -- no, I didn't want developer tools. I want full screen. You can see it's going to persist 2. 3 gigabytes of source code when I run it. I'm clicking the run button. It's running in the code. It's going to take one minute. DOMINIC: Wait a second. Is that just SQL? The SQL we would use for databases? URI: You can recognize SQL elements like request or where. But BigQuery has an interesting feature, you can run JavaScript as part of your SQL query as you see above. DOMINIC: I love that. URI: Basically we are using the compiler inside of BigQuery to process all the source files, find all the methods and functions and extract the comments and the bodies of the functions and methods. DOMINIC: I see. So, we use the TypeScript compiler which we use -- we take advantage of the AST to then find information we need from those files such as the function and all these things. URI: Right. And we do this in the cloud really fast. It's gonna finish in a few seconds. And if you are not familiar with the AST abstract syntax tray, you can find it with the same title on Angular op. We have the results. Let's hide the editor. And as you can see, we have here a big table with basically the comments and the text. Some -- oh, check it. We should. Should attach. Let's go to the last state. See if there is anything interesting there. So, basically we have here -- yeah. Basically we have here -- come in. We have here 300,000 comments in our dataset. DOMINIC: In just a minute. URI: Yeah. Wow. This is like really long comment. Oh. This is espanol. DOMINIC: Si, yo habla espanol. URI: We have this large dataset, this big JSON file with 300,000 comments and functions. Are we ready? DOMINIC: No. I'm gone no stop you right there. We are not done yet. We have all the data. That's great. But the next step is actually to clean the data. Because the data, well, it's text. Right? And we have to do a couple things. It's not as tidy as we want it to be. URI: We have seen some comments in Spanish. DOMINIC: Yes, exactly. And that's why the first step would be to turn everything into lower case because we want to remove the noise from the dataset. We also remove URLs because that also just adds noise to the dataset and has no added value, really. And remove non-English comments. Because learning one language is different. Right? And learning all these languages would be even more difficult. And then also to reduce the noise and complexity, we replace function names and arguments by just very generic place holders. And we also do that on an AST basis. URI: So, basically the comments no longer contain the function names and arguments. Function name place, argument one place holder. So, it's easier for the model to understand that a specific word in the comment is actually one of the arguments of the function. And once we have done cleaning, we start... DOMINIC: Almost. It's like preparing dinner. So, it's like a recipe and you have certain steps, things you have to do, right? If you want to make a tomato soup, you have to cut the tomatoes in a specific shape for a tomato sauce or soup. That's what preparing is all about. For instance, we have text. And obviously machines, they don't work with text. They work very well with numbers. URI: Numbers! DOMINIC: Exactly. That's what we have to do. URI: We have to take the text of the comment and convent it into a list of numbers. So, we create some kind of a dictionary like you would have an English dictionary. But in this case, it's not English to Spanish, it's English to number. DOMINIC: And also the other way around. So, it's both ways. URI: So, when we feed the input into the model, you convert the dictionary into a list of numbers. When the model predicts a comment, we use the dictionary to convert the numbers of the model predicted into text. DOMINIC: That's right. URI: That's right. So, are we ready to train it? DOMINIC: No. URI: Why not? DOMINIC: Not yet. We have to come up with a model architectures. There's a couple of things you can do. But for training a model, you would typically use Python as we already mentioned. And there's a library called TensorFlow which lets you create and train the models. And you can think of TensorFlow as like this box which with a lot of Lego blocks, you can think of the blocks at Lego blocks and mix and match and stack them on top of each other to build the model you need. URI: How do you know how to do this? DOMINIC: You would look at similar problems. You wouldn't start from scratch. You would look at similar problems from problem domains. URI: Which is to go to code? DOMINIC: For example, translation. Say German into Hebrew, you want to translate code into English. URI: I will do it live, translating Hebrew to English. Number one -- DOMINIC: Meaning I have a bird. URI: In Germany, that would be -- [speaking German] DOMINIC: You could say that. I wouldn't. URI: All right. DOMINIC: Anyways. So, what you do is you look at very similar problems and then you -- you can start with model two already defined, try to tweak them and stack the building blocks. We're not going into too many details here. But that's basically what you would do. URI: We took an architecture, encode the decoder. You can find it in the repository. We open source everything. Unlike... and then let me show you how we train this model. So, we could install Python on our computer. But that wouldn't be the way that I would recommend to somebody training -- yeah. That wouldn't be the way I would recommend to somebody who is just getting started with machine learning to do it. Because you know setting up your computer is like half a day of work. There is something better. It's called Google Code Lab. DOMINIC: It is awesome. If you know stack bits, it's like stack bits for machine learning. It's not a code editor, but think of it as stack bits for machine learning. URI: And I have the worksheet, I'm going to run the command and cloning the repo. It runs the commands somewhere in the Cloud. And copy our code and creates a small dataset. Let's look at the dataset. It's a super-small dataset, just five comments and their functions. The comments have been translated to more complex for us, but simpler for computer presentation, the object syntax tree. And you can see the comments and we replaced the text with argument number one, argument number zero, that was the preparation. DOMINIC: Obviously those are very important to predict meaningful and correct comments. For the first step of this model, we just replaced and reduced the noise to reduce the complexity. URI: We downloaded the code and the model and we can run LS minus L to see -- oh. We need elimination. We can run LS to see on the remote machine. And we can see it has all those files from our repo. And we are going to run the training that will take probably a moment or two. So, basically right now what are we doing? DOMINIC: So, we're just started the training process. And as we can see, there is something called epoch one of five and this epoch is just another name of iterations. We have a dataset that contains five sets of abstract ASTs and the comment for that function. And one epoch is going through all the data at data points, data entries we have in our dataset. And the training is really just an iterative process going through all of these examples over and over again until that function, this model, produces, well, somewhat good results on a variety of inputs. URI: Right. So, it's almost done. And while it's working, we have trained it in Python, right? But we do need to figure out some way to get it into JavaScript. DOMINIC: We can run Python in the browser or from within JavaScript. It makes no sense. We have to come up with this missing link in between. I think we've already mentioned something that we can use, right? URI: Yes. So, basically there is a TensorFlow JS which is TensorFlow for JavaScript. And we have one more thing we can -- we need to do so we can use our model inside TensorFlow JS, which is basically convert it into JavaScript model. Which is a JSON file. So, here I'm running this script to convert the model and create a ZIP file with the model that has been exported. DOMINIC: You can think of this as remember that this model exists and the machine comes up with the implementation. This is what we basically do. We export the implementation of this model to a format that we can easily consume from JavaScript. URI: And the implementation is just a bunch of numbers. We can download the ZIP file. Whoa. That's fast. I would have extracted it, but I already did. Do you know Wiley synths JS? DOMINIC: It's an awesome tool that allows TDD. URI: We are not using TDD. We are going to use what we just downloaded. We have TScomment predicter that has a comment predicter plus that knows how to load this model using TensorFlow JS. You can explain what I'm doing while I'm doing it. So, first of all, we need to load the predicter. DOMINIC: He's already explaining it. URI: Comment predicter. DOMINIC: I don't have a job. So, yeah. URI: Sorry. DOMINIC: We put it -- we wrap everything, all the TensorFlow JS stuff in an abstraction. It's a thing called comment predicter. We're loading the model that we just saved and converted into JSON that we can easily load it. And that uses generators -- JavaScript generators. And now what we do is create a function. One example that we want to feed in, that is the input to the model. And it's just a string, right? And then in the next step, awesome function, technology is awesome. Good. URI: Love the result of finding the predicter to predict with the function. DOMINIC: And we're feeding in. What do you think is gonna happen? Hopefully it produces some comment. URI: It's thinking, you see? DOMINIC: Let's see. Remember, this is a very, very, very small dataset. It was only five examples and, well, do you think that the results are gonna be good? Bad? URI: Or no results? DOMINIC: Or no results at all because machines never work? URI: Yeah. Seem like my computer is tired. Let's give it one more try. Maybe it should be -- doesn't like this kind of... so, yeah. Our model is lazy. We created a lazy model. What have you done? DOMINIC: Just like us. I would say. URI: Yeah. Anyway, so, to be honest, this model was not very impressive. It wouldn't to a lot of stuff because we only tried it on five functions. And apparently it's all lazy. So, it would probably predict some nonsense. DOMINIC: Maybe that's a sign. Maybe there is no comment because -- URI: There is no -- DOMINIC: There is no comment. URI: Yeah, there is no. Now it worked. And as you can see, it's not very intelligent. What it says is technology, technology, technology, technology. TT. DOMINIC: Very important. TT. URI: Very important. DOMINIC: That's typically how I end my comments as well. URI: It still is impressive because the model learned there is slash in the beginning of comments and space between words, I guess. DOMINIC: It has learned something. URI: From five examples. Not too bad. DOMINIC: Let's take a look at a real thing. URI: Yeah. So, we trained the model for an hour on a dedicated -- Google has this dedicated machine learning hardware called TPU. So, if we train this model regularly on our machine, I did it overnight, it took seven hours just for one iteration and we had to do hundreds of iterations in order to get it good. But with the TPU, it takes like 5 seconds. DOMINIC: machine dies. It can't do it. URI: We saw this worked and we wanted to get it into the Visual Studio Code extension. How would you do it? DOMINIC: Angular has schematics, scaffolding. And there's a tool calledEe yeoman. It's a scaffolding code, yo, code. >> Rob San Martin: We'll call it... DOMINIC: Lazy octopus. Just to match the theme. URI: Yes, there's Angular-released names. No description, no repository, NPM. And basically at this point we have VSCode extension. The code for us. DOMINIC: Awesome. This is machine learning. URI: And as soon as it finishes, we also want to install here our model. And... DOMINIC: Which we published to npm. All this shows you that it is not that difficult after all to consume these models. You can publish them to np. You can use the tools. Don't be afraid of machine learning. You don't have to do the data science yourself. Or find someone who knows the data science. You can get started and be in your comfort zone. URI: Just download TensorFlow and start installing it. And if you ever created a Python environment, you would know how much time it takes to get this installed. Here we get it in three seconds from npm. You don't have to do anything. Just npm install. Now we have this lazy octopus. And we can open the new project in Visual Studio Code. And if we look at the packet JSON, this is in code extensions, you can see it defines a command. A command is what happens when you open the command palette. When you create a new extension, you can add something to the list of the commands. We'll add a command... DOMINIC: Add comment to function. URI: Thank you. And then we would like to implement it. Actually, let's look at the implementation that comes by default. It should show an information message saying, hello, world. Let's just do a quick check to see if that work. I'm going to hit F5. And hopefully this is going to build the extension and open. Oh. Errors. DOMINIC: Npm watch. What is it? URI: Oh, so many errors. DOMINIC: Okay. Skip the check. There's a flag in the conflict file that let's you skip the check. URI: Read about it at home. It's magic. This is the real magic. [ Laughter ] DOMINIC: We appreciate that. That's good. URI: All right. So, now we can press F5 and we have another Visual Studio Code inside our inception. And then we can press -- oh! We see a new command edit. And when we click it, it says hello world. DOMINIC: That is awesome. URI: So, the only thing we have to do now is just to implement it. DOMINIC: Right. We just installed all these packages that we've published to npm which contain the trained model and the abstraction. So, we can easily just, you know, implement everything here inside the Visual Studio Code extension. So, let's do that. URI: Yeah. Let's start. Yeah. I create -- I need some utility functions. Lets me create these easy field functions. So, this is cheating. Just coded it beforehand. But basically these are functions to fill the compiler to get the kind of function you are kindly looking at in the editor. And we have code that calls the functions. Basically returns the current element -- the current node, the current TypeScript element you are looking at and find parent function. Returns the function you are currently looking at. So, let's do a quick demo of that where we just display the function we are looking at. Get back. And reload this. And now when we run the command, we can see that as soon as you click add comment to function, activate the extension, and it gives us the function we were looking at. The same function. And -- DOMINIC: This is exactly what we need for our model. URI: Yeah. That's the input from the model we get. And let's load the model, right? DOMINIC: Yes, let's do it. URI: So, importing and creating the model from the npm package. And then the last thing we would need to do is like, we are going to show a progress bar because this is going to take a few seconds to predict the comment. It says, predicting comment. And this will call the predicter, the predict function. The one we used in the text we did. Function test. And then it will insert that comment at the starting position of that function. So, just before the function, the comment will be automatically inserted. Are we ready to see this in action? DOMINIC: Yes, I want to see this. URI: Okay. DOMINIC: And by the way, this is nothing that we can rehearse. It's machine learning after all. We don't know what's going to happen. URI: We are going to run this function at time series. Will it work? Predicting comments! What is that? DOMINIC: Satisfaction offer constraint to a function. All of these invocations are -- unless otherwise noted. [ Applause ] URI: Shall we try another one? DOMINIC: Creative, I would say. URI: Okay. Let's try another one. I would say this -- oh! Speedy function. A speedy JS function has the async model and contains use speedy JS directive. It doesn't have it, if I run it and run it again, will that be the same thing? DOMINIC: Well, I would guess, yeah, that makes sense. Observe returns true when objects are shallow, equal. Yes. That's what I would expect from observe. I guess. URI: Magic time. Let's see. DOMINIC: I hope it's not gonna break this time. Whoo! Very nice. Okay. URI: So, I think we can summarize. What have you seen here? DOMINIC: So, before we talk about our learnings, I guess there's things we can still improve. And we definitely want to continue working on this because it's just fun and fascinating. So, overfitting is a problem. Overfitting means that the machine really just memorizes the entire dataset. That's why it's so bad at actually predicting proper comments for something that it hasn't seen. So, that's something we should definitely fix. URI: Yeah, I mean, we only tried on 2,000 functions. So, it has a small dataset, it can memorize it. But once we go bigger, well, it won't be able to memorize everything so it will have to be smart and learn. DOMINIC: Exactly. But then there's the problem of memory constraints. If you have a very, very large dataset, you have to come up with what ways, how to reduce the memory requirements and all of these things. So, that's another thing we have to do. URI: Right. But that's not your problem. Because I think the important thing here, you can use the help of a data scientist for the dataset. You can just do the JavaScript integration. Like integrate what they worked so hard to create into your application. DOMINIC: Yeah. And basically what we've seen is that how easy it is to get started with machine learning. Enin the JavaScript world, right? We can easily use TensorFlow JS to convert Python models and integrate into a virtual Code extension and all of these things. URI: Yes. And basically we know that text summarization, which is what we tried to summarize the code into a content is possible. It's an active area of research and people are doing it. So, we believe that with some more work we will get perhaps less funny, but more useful results. And we think that tight integration with existing like Visual Studio Code is crucial to success. This is where you come in. Where you can take machine learning and integrate it into your environment, your application. And -- DOMINIC: I guess the main takeaway is that machine learning is exciting. URI: And it's coming to JavaScript. DOMINIC: And it's coming to JavaScript and that you can all get started. URI: Yeah. So, you can see all the code that we created and the comments we did last night and this morning and after this morning and five minutes ago in the repository. The slides are here. We'll also publish everything on our Twitters. And with that... DOMINIC: Thank you very much. [ Applause ] >> Thank you. Thank you very much Uri Shaked and Dominic Elm. Well, in a few moments we'll have Elana Olson over here and... yeah. Elana is gonna be awesome. Oh, so, we're waiting a few more moments for track 1 to finish up and for everybody to come back. Just a moment. Technical challenges. Okay. I think -- okay. Elana Olson is our next speaker. And she worked at Google. First, helping people migrate from Angular JS to Angular. And then helping people just develop with Angular. Which is great. Which is awesome. And she's a student for software engineering at the San Jose State University. And she's into software developing and -- in her spare free time she loves adventures and hiking. Especially in California in the mountains and the different sceneries that you have in California which is beautiful. So, Elana Olson. Thank you. [ Applause ] ELANA: Thank you. So, again, my name is Elana Olson. I hope you guys have been having a great day so far and enjoying all the different talks you have been hearing today. I'm gonna talk about how you as developers and find Angular more easily. How to access resources and build applications faster. Is and so, most people here today already know Angular. Some are experts. Some are just beginning. But everyone is in a different place on their learning journey. We're all just boats sailing in the sea. We have different knowledge ranges. Knowledge is often specialized. Even people on the Angular team have stuff to learn about the Angular platform. And at some point, you'll be called upon to teach others, to teach your coworkers, Angular. As you guys grow and expand, you'll get more people and as you had to once learn Angular, you'll have to teach someone else. So, it's important for us to understand how we can quickly get started. Today I want to talk about who this talk is really most useful for. If you are learning Angular for the very first time, this talk is gonna be great. If you're going to be teaching someone, which is basically everybody here today, about Angular, this talk will also help you. If you're searching for the best practices or you want to be able to find resources faster, this talk is really going to be useful. We're gonna cover three main thing. First, we're gonna actually create an Angular application from nothing to deployment. Then we're gonna be able to find resources more easily and expand your application with these libraries and other Angular resources. And finally, we'll do over how you can contribute to the Angular world. What you might want to do with your team or how you want to help this effort. So, I work as a developer relations individual on the Angular team. That means that I'm talking with developers, understanding your experiences and your needs and translating that into tools, documentation and prototypes that will help you directly from your feedback. I study software engineering. I love traveling. I -- that's why I'm here today. And also to share with you guys about Angular. And in my spare time I like to play lots of volleyball. So, let's get into how we can create an Angular application from nothing to deployment. We see here -- here's a flow diagram -- of exactly what needs to happen when you're creating an Angular application. You first are gonna set up your development environment. Whether you choose to prolong or put off the development environment setup and just start using StackBlitz, which allows you to immediately start building. Or if you want to set up your CLI which involves downloading Node. js, installing Angular CLI and choosing a package manager. Then we move into your building which you're going to start using components. And you'll be able to start navigating through different views with your single page application. You'll then start managing data and tak ing in user data. Compiling your project and finally deploying it. You have an application. So, the first step of this getting started guide is setting up your development environment. And as I said, StackBlitz is a really great way of getting really quickly into programming Angular. You don't have to do all this backend stuff. And instead you can just make your application and then build it locally at the end. But if you're like me, where you wanted to be able to build it from the start and have your setup environment ready for any application, then I wanted to learn all the steps necessary. So, to build locally, you first need to install Node. You can install what's called nvm or Node Version Manager if you want to have lots of different Node versions for different projects. That way on this one project I can use Node version 8. And on another project, I can use Node version 10. And you can switch really easily. But this is an optional requirement. Then you're gonna install a package manager. Whether you choose to use npm or Yarn, both of these will help you install all of your dependencies for your projects. You'll install the Angular CLI. And then you're going to create your application for the very first time with ngNew. And for our example application, we're going to call it a fish app because of the theme. You're gonna open that directory. And then you're gonna serve it. And you have this application. And it should look something like this. Everyone's very first application before they've added any code to their project will look like this. You can actually learn more information about how to build projects from your opening page. We want to add our own code. So, let's get to the building step. Now, when we're building an Angular application, we're gonna start using components. And components are really useful because they help divide our entire screen into view sections. So, that we're creating one component that we can actually duplicate across views. We can create components really easily with ngJen ratecontinent and then the component name. And it inputs it into the Angular CL suspicious adds that into the declaration array in at modules which I'll show very shortly. Let's take a look at what our beginning application might look like. We have some fish profiles. And each fish profile is a component. And when we create that fish profile component, every component is given a selector, a template URL and a styles URL. Now, the selector allows us to take that component in brackets and put it any HTML file and say, okay, we want this component here and we want this component here. So, we can duplicate it over and over again in different views. The template URL helps us define the HTML associated with that component. And the styles URL also helps us associate the styles with that single component. So, every component has a TypeScript file, an HTML file, a CSS file and a spec.ts for your tests. Now, like I said, when we create that component, we're actually changing the app module. You import it -- when you do ngGenerate, it automatically imports that component name, fish profile component, and adds it to our declarations array so that your entire application is now aware of that new component. Let's break down the original screen into our different components. Here we actually have two different components. The first is the tool bar. And the second is the fish profile. Now, the fish profile is actually comprised of a top of Angular material components which I'll go into very shortly. Angular Material is a great way for creating and adding components that are already pre-built and follow material design practices. Material components, they implement and they follow common patterns so that you don't have to build standard lists and tables and navigation bars. They're already ready for you. So, one example of an Angular component is called Macard. An Angular Material component. It has a Macard header, Mac card content. I can put it inside my component and have pre-defined components already in my application. Now, this Maccard is comprised of your Mackard header and content. And all I had to do is include it in the specific headers and content, and it did it all for me. Angular Material is really great for speeding up that process of just creating components really quickly and standardizing them with a design. Did you notice the director directive that I slipped in that code? Here it is. Directives allow us to do interesting things to our code. In this example, we have an array called fishys. And for every fish, we iterate over it and we produce a mat-card. And so, I had a puffer fish and I had an angel fish and lots of other fish. And every single one of the fish had their own profile duplicated in a list. We have created components and now we want to have a single page application. The way that looks is here I've created a menu. And we actually have different pages that we will navigate to that will have unique URLs. The first thing you need to do is to go into your app modules and import router module. Then you define paths to get to different applications. Different pages in your application. So, our home page, which is the empty brackets, is our fish profile component. And then we have another page called fish cam which actually links to a different Angular component that displays a live fish record recording. And then we are going to add router links into our menu that we've designed so that we can link to our home, we can link to fish cam anywhere in our application. Let's rewind a little quickly back. We can see here now we have our home page and we have our live fish cam page. These are our two router paths so far. So, our next step is to be able to actually manage all the data. We're not just gonna be storing things in arrays. We're probably going to have a database or an API that we want to import data from. And that's where services come in handy. Services will contact your HTTP client and they will interact with an external API or database. And they will do queries for you. And all the data coming through will go into your service and then injecting into your components. So, that any data shared across components is provided by your service. Services are great because they help you fetch data. Specifically data that is used across all components. And that data is protected because -- and it's distinctly put into one area which makes it have easy to know where your data should be stored and where it's coming from. And every component, you'll just inject the service and then you have access to that shared data. You'll use the simple command of ngGenerateService and then the service name that you want to use. And that will do lots of things like import injectable. And create a service. And that way, in this simple example, we're just uses an array of data. But we would normally be connecting to Firebase, something like that. And adding data or getting data. And then, when we go to a component, we import that service and we inject it into the component so that we can get or add data via that component. And it's not data that's specific to the component, but it's data specific to your entire application. Now let's talk about form. We have all of this amazing single page application. And you want to be able to now take in user inputs. Forms help you capture and validate user input. The way that they do that is you can add specific validators to every single input to make it required or to have certain form requirements. So, if you're adding an email, you want to make sure that it's an okay email to import. And you can track these input changes. So, let's take a look at what a form would look like. If I want to have more fish profiles, I want to ask people to submit these new fish profiles. We're going to take in a name and a description and an image URL to be able to display those fish profiles. We're gonna be using reactive forms in this example. And so, what we want to do is import form group, form control and validators. And that way we can have a form group that is a group of lots of form controls. And each of those form controls is the name, the description and the image URL. Then in your code, you'd define an Angular form and attach that form group name. And then you'll also have in each input with a material form field, you'll have the form control name. That way any input that you're given in that form, you can then add to a submission in your database. You're collecting new data. Finally, you need to import certain things into your out module like reactive modules. We also use material form field. And when you use material form field, you need to also import mat input module. So, we're now at our last step. We can deploy. And there's lots of different ways that you can deploy your application. The common way to use is Firebase. And there are lots of steps provided on the Angular.io getting started page to help you understand how you can deploy on Firebase. When you have an Angular application and you're using Firebase, you're going to want to do through Angular Fire, which is a specific way of using Firebase in conjunction with Angular. Let's do a demonstration of this application now that we've built it. It's a very simple application. You can see here we have all of these different profiles that we have created. We have these different routers links. So, we have a home, we have a new fish profile where we can add a submission. And then we have this live fish cam that links to I think the longest standing video on the Worldwide Web ever. It's just some aquarium in someone's house. Or their office, maybe. Sometimes see people walk behind it. But this is completely accessible. And we've just linked to it. And that's a whole new page we have. Obviously your application isn't going to be as silly as this. But this is the base for all Angular applications. Is that you're going to have components which in this case we have fish profiles. We have a submission component. We have a fish cam component. And we will have routers that you can route to different paths on your application. You'll have inputs. So, you're gonna want to use forms. And you will always want to use services when you're using data that's shareed across components. So, we're kind of pros now at Angular. Because we know how to build applications and do all these crazy things. We can use components. We can have single page applications. We're balancing with everything. And you can build a way better application than what I've shared today that's way more complex. But it's really based on this foundation. So, when we have this application, and you're already pros now, you want to be able to find resources a lot more easily. And in order to do that, you have to trust those resources. And go through a vetting process so that you can understand what's good for your application, what fits? Where do you find these resources? And so, we created an application called Angular Ecosystem that compiles all of the best practices today of libraries and Angular tooling, Angular resources. And allows you to compare them really quickly based on bundle size, based on Angular compatibility and based on accessibility with good documentation, frequent maintenance. We want to be able to speed up your integration with different tooling so that you can rapidly expand your application. It's not just a fish app. But it's a fish app with a really cool library that's installed. It's a fish app built with the best practices in mind. Let's take a look at what this Angular Ecosystem actually looks like. So, if we go here and we want to search for something like let's just say UI for now. UI, we don't really know what we want. We come up with a huge list of information on different UI. So, here we have Angular Materials. And we're provided with link, a really short description in this case, but often they have longer descriptions. And we can see here with like Angular Playground. It supports ngPad. And this is what we call Angular compatibility or Angular features. If it supports ngAdor ngUpdate, it means that it can integrate with your Angular application really easily. And they built that in mind for this. It provides you with lots of helpful links. And eventually will be measuring bundle size based on a bundle size measurement tool. You can see the bare bones model of that integration into your application and add up these numbers and see how big it would expand your application. Let's say you browse through this list, but you're not really happy with your results. You can actually submit a new resource. If you think that you have a fantastic new resource, or you know of one, or you're building one and you think it should be on this list so that everyone can start using it, this is where you can actually add a submission. There's some standards for how we want to approve new applications. And they will be passed across the Angular team. So, the current applications that are on this recommendation have been pulled directly from the Angular documentation. And from teams that we've already vetted essentially. But we're looking for certain things that are common across tons of applications. As well as libraries and other useful tools and resources. So, let's just say, I don't know, we want to make a fish app. And it's a type of fish, and it has some crazy description. Some related search terms like fish and application, UI. We are going to add -- now just going to be local. A funny URL. Let's say it's the same as the Git repository. Doesn't have an npm package. And but now let's just say it's APIs. So, we submit that application and we're given a status to go to. And so, when that status is changed, it means that your application is either been approved or denied. And so, as an admin, I can find -- I'm signed in. And now I see this fish app. It's been submitted as well as some other applications. And I can go in and review it and say, hm, this description's not so great. Maybe we should expand upon it. Or I know in application doesn't support ngUpdate, or it does. And so, then I will go in... for now we're going to not approve or deny anything. But then we can go and see all the applications. And everything that's already in this database. And browse through it. So, if you don't know what you're looking for, you just kind of want to expand the application, you can go through and look at everything. Read the description and kind of understand what we're looking for in this database. And that way you can search. Very easily. And compare all the tools very quickly. On the demo. So, in conjunction with everything that I've already shared now, let's talk about the component structure of how this application with Angular system was actually built with. We have our app component and we have about nine either components and they're remitted to the service in some way. We type in the search entry, typing in the search bar. And that goes to your service and says, hey, I want to query the database with the search entry, matching the search terms or the title or the category. And then that service returns values into our results. And the result list component provides all the information in that table that we were comparing. And at the very bottom you can add a new submission which will bring you to your submission status. All of these are unique components. And I could copy this new submission anywhere in the application and have lots of duplicates if I wanted people to submit a new application on every single page. And then we look all the way over into the admin console and we actually see that the admin console contains another component. And that way I could have specific URLs designated to each submission. So, that the admin console is kind of a shell, and each submission is inputted into the admin console and filled out. You would have admin console/the submission ID and it would change each submission you have. Let's take a look at this admin console. So, you can see it visually now. We have the admin console. And then inside it is that submission. And we break down a little further and we see that the admin console is actually comprised of a ton of material components. Crazy idea. Those components are already built for me. So, why shouldn't I just use them? Really easy to import. Import them and put them anywhere in your components. And we're good. We have the side navigation to scroll through all of our reours sources. We have a material card, an Angular form. We have material buttons. All of these are pre-built components that I really like to use because they're super-easy to use. So, I talked a lot about submitting a resource. And I want the community to be able to expand this application. What are the criteria for approval? Good documentation is always a great start. We have to be able to understand your application before we can do anything with it. Frequent maintenance is also important. And if you can provide simple integration with other languages, that would be great. On the technical side, if you have npm packaging, really easy to install your tool. If you support these ngFeatures, ngAdd, ngUpdate. If you have a small bundle size, which you can actually go to the bundle measurement tool that will be released soon and measure your application and self-report it. That can help us understand how big your application would be if people started integrating it. And if you have automated tests. So, how can we be part of the ecosystem? Submit resources. We won't know about your application unless you tell us. And we want to accept as many applications as possible because there's so many great tools that everyone is building. And it's really great when we can integrate them with the entire Angular ecosystem. Help us establish more criteria for comparing resources. So, if I missed something here today, and you were like, dang. This is a really great way to compare stuff and she's just really missing it, send me a message on Twitter. I think my Twitter's on every single slide. And you can help us define better criteria. And if you want to expand this application and be a contributor, that would be really beneficial for the entire Angular team and for me. So, if you can submit a PR, that would also be great. Here are the links in order to access ngEcosystem. It's live on this crazy weird URL. And if you want to go to the GitHub link, it's mygitHub/ngEcosystem. Adding criteria, if you want to message about issues or submit a PR or have some crazy idea about expanding it, send us a message there. Thank you very much. If you want access to this these slides. It's found here. It has all the useful links that I talked about today as well as the step-by-step process of getting started with your application. Thank you so much. Have a great day. [ Applause ] Angular sticker. I somehow brought Angular stickers this time. Find me. >> Thank you, Elana. Thank you. We are going to have a shorter break than planned. so, we're gonna be back with the sessions in 20 minutes. 4:05. 4:50. And the speakers in this room, you're needed in track 1 right now. Thank you. . . . . . Break! Next: Mocking made easy Dave Cooper >> Hi and welcome back. Next up we have Dave talking about mocking made easy. Let's hear it for Dave! [ Applause ] DAVE: Hello, everyone. Thank you for having me. I have been to a couple of AngularConnect. But not presented. This is mocking made easy, my talk. It doesn't mean too much. The probably more literal title we can take here is making your applications easy to test and run locally so you don't have to spend loads of time with mocking solutions and spend a lot of time writing your application. Yeah. Rolls off the tongue. Those are the titles I give to get this. And the title is actually mocking and glocking. It's hard to find a picture of a solid gold gun. So, just had to improvise that. Anyway, I'm Dave. And I am a software developer at Uber Energy. And I like open source stuff. Really like testing. Really like mocking which you're about to find out. And you'll probably be sick of hearing about it after this. But anyway, really, really quick disclaimer. I have massive baby brain. I have a 5-week-old daughter who is just here. If I can just be really cringy. Get a photo up on stage and we can all be collective like, ah! awww... there we go. Thanks. Excellent. Okay. Cool. Let's actually cover something that you paid to come for. Cool. So, I want to talk to you guys about testing and running web applications locally. Specifically mocking and how we do it. And what I think the problem is. And I'll probably -- have a few different points over the course of this. But I think this is a topic that's been stagnant for quite a while. So, I sort of tried to think about things a little bit differently. And explore some of our current sort of mocking solutions. And what I think a slightly different way of doing this is. And you can form your opinions and let me know how much you love or hate it afterwards. But anyway, running a web application locally on your labtop, whether we're developing features or improvements or trying to re-create bugs or in my case, cause bugs, that should be a really painless process. And test the paths your application can take, whether they're happy or unhappy experiences. That should also not be a pain. If you need to do mocking or feel mocking is appropriate, that should also not be a pain. And whiles all of this is happening, your application state, it needs to be able to bend to what you want it to do it and maintain the integrity of the data you're working with. Referring to happy and unhappy paths, the user is signing up. They can do that successfully or make a payment, they can do that. Et cetera. And you can see things that aren't quite happy paths. Customer's in debt, payment fails. Unable to retrieve records. Maybe your server is throwing back a 500 orwhatever. And I'll probably interchange refer to happy and unhappy paths. Or refer to them as scenarios as well. Just to give you a head's up on that. This should be pretty easy. I'm sure internally you're all groaning because it's not. A lot of places I've worked and a lot of projects I've looked at, it's not really that easy if I come up to someone and ask them to bring up in a customer in a particular state. Maybe they're in debted or maybe there's something weird or funky about them. Usually people have to tweak around in the database or they're pulling stuff from somewhere think probably shouldn't. It kind of sucks that's not a snappy sort of thing to be able to bring up entities in those particular states. So, I guess we can quickly explore how we typically see this being done. So, you could run your application against a production service. If you do that, you will get sent to developer jail. That's a pretty -- that's a pretty sort of cardinal sin, I guess. Some people do it. I mean, I've done it in projects before. It's a bit naughty. But in developer jail, you sort of have to argue about spaces and inverse of Emacs and what the best language is. It's obviously TypeScript. We could run our application against sustaining a UAT service. Cool. We're not touching customer actual live data now. Which is pretty cool. Unfortunately, you'll also go to developer jail if you do this. Because typically you're accessing data that's on shared instances or maybe, you know, if you're accessing something that's coming from a database. The schemas are out of whack. Or you don't have the right data in there that you want. So, that's still not really great in my opinion. We could start to go down the containerization route and run everything against a local copy of us like our production services. Or staging services. And that's also sort of starting to head in the right direction. But unfortunately, it's still a little bit of a pain and you might go to Dev jail. You know, getting these things set up is typically an after thought when you're setting up a project. You're not thinking about dockerizing literally everything and getting that all nice and polished so you can work offline or, you know, work wherever. So, I'd probably, you know, I still sort of slight -- shy away from that when I can. But, you know, we've all heard of these things being done before. I've already admitted I'm guilty of doing these things. I'm sure 95% of you are guilty of it. And some of you are thinking, why we don't we run a mock server? We're getting into cool territory. We can definitely do this. You know, there's so many options out there. You've got things like JSON server, API mocker. That number I've got down there is pretty close to how many alternatives there are on npm if you have a look. Alternatively, if you're not familiar with those, or might not have too many endpoints in your application, maybe roll your own API. Maybe write a small Node service to serve up some data if you have less than ten endpoints. None of those are bad solutions. And gets you there for most solutions. Especially starting from scratch and building up. Rather than getting too tricky, you know, you can do that. A really quick example here is what a config looks like for JSON server. For those of you unfamiliar, JSON server allows you to define a JSON file. It's keyed by the endpoints that you want your application to serve up. And then the values there are just the responses for when you hit those endpoints. So, here we have post, component and profile. And you can see the respective responses. That's pretty cool and incredibly popular. I'm definitely not discounting that. I went to start writing an example for API mocker and I got a little bit annoyed because there was so much config. So, you can take a look at that yourself. The problem that I find with things that start to get a little bit more complex like APImocker is that it's pages and pages of JSON configuration and then you start to introduce things like JSON path to, you know, define different scenarios. And for those unfamiliar with JSON path, Texas it's like XPath, except 600 times worse. What can we do? Now we get to the fun part. We have a little library that I wrote called datamock. And my fiance came up with this logo. Dave, I created this logo. It's two of your favorite things, obviously, and ransom letters. Which I thought was odd. And someone asked if it was giving or receiving, and I got even more confused. But, yeah, anyway. We have data mock. It uses a code-driven config. That's nice. You're not writing loads and loads of JSON. It doesn't interfere with your existing codebase, which is really cool. And it's similar to Angular multi-mocks which is what Ed, in the audience there, he wrote that. But it's a framework-agnostic version that works with everything, Vanilla JavaScript, Angular. Didn't know if I could use the R word. I redacted a couple thing. We have blank and blank Native. So, you can probably work out what those are. It works with XHR fetch, if you're working on a bit more legacy that uses XHR under the hood, or something popular like Axios that uses XHR under the hood or the Fetch API, it works with both of those. Super quick and easy to set up. Which is what we're about to find out. And if supports scenarios which is my favorite thing about it. And the thing that I think really sets it apart. So, let's jump into some coding which hopefully this doesn't go too badly. That? Yeah. What I have is a small Angular application. It's a widget factory. It is contrived. But all this is doing is fetching a bunch of widgets from a node service and displaying them. And here I have ten widgets. For context here, a widget is just an object that contains an ID. So, we got some sequential IDs here and we have a button at the top who allows us to add a new widget. And my application doesn't work quite as you probably expect. It doesn't retrieve something insensible. It gets something with an ID in between 1&100. And basically this application was built to handle certain types of widgets. And I guess we could pretend that these things were a little bit more complex. Maybe they have different categories. Maybe they behave differently depending on what sort of widget is being rendered on the screen. Maybe there are other things. Maybe there are unsupported widgets. Or maybe there's invalid data coming back from our server. Or any of these things that we can't necessarily predict. And when we're developing this application, we want to be able to, you know, make sure that we've actually coded this correctly. And sometimes that can be a little bit difficult. So, what we're gonna do is we're gonna jump into our application here. Hopefully we can see this okay. Is that big enough? Yeah. Okay. Just shout out if you need it to be bigger. So, basically, you've probably all seen this screen before in your Angular applications. I've imported a random number generator so I don't embarrass myself trying to generate random numbers. What we're going to do first is mummic the Node serve and then get scenarios and see how easy it is to toggle between these. I'm going to kill off my Node service that I have here. That can go away. Now I don't have a working application. What I can do here is first of all, I need a way of I guess an entry point to inject in the application. As we have seen before, we have an if block, if it's in environment for production, then do something in prod mode. Similarly, we're going to see if we're not no production. Not in production. And we're going to do some stuff here. So, we need to import a couple of things. First of all, import a function called inject mocks. Cool. All right. So, we can add that code here. And we need to give inject mocks some mock data and tell it how these mocks should behave. Fortunately that's pretty easy. So, let's -- let's define a variable. Scenarios. Now, this is all fully TypeScript-supported. So, we have typings for our scenarios. Do that. The scenarios. And all, I guess, this set of scenarios is, is a mapping of a scenario to what we want our mock data to look like. And the minimum requirement for a set of scenarios is that we have a default scenario. So, here, I'll just quickly jump over to our entire application here. We can see that we're calling two endpoints. We're calling the widgets endpoint to get a list of all of our widgets. And we're calling a new widget when we want to get a new widget. So, first of all, let's have a look at what a mock looks like. So, there are only five things that you need to describe a mock with data mocks. One of them is URL. So, it's just a regular expression. Matching on the endpoint that we want to mock out. So, we've got widgets. The next thing is the HTTP method that we want to mock for that endpoint. And lastly, for the set of required things, is the response that we want. So, I think we've probably want an array of ten items. See if I can remember how to do this. And we want the IDs for them. Return an object from them. Probably want the -- I think that that will probably do that for us. And the two optional things that we can also define for each of our mocks is a delay in milliseconds. So, we can sort of make it simulate as if this request is really hitting our HTTP server. Which is nice if your application's got things like loading spinners or loading animations and stuff so you can see that in action. It gives you a good look and feel while you're doing this. And then lastly, we've got a. So code. Which is just the HTTP response code. And that's it. So, we can do that for all of our endpoints that we have here. And we should -- we should be in business. So, we'll also do it for new widgets. Yeah. Response here is a little bit different to the one above. I've got that rand function that I imported before. So, just make it return one widget with a random ID. And we'll keep maybe the delay for this 2,000 milliseconds. And keep the response code. Today. Hundred. And there we go. All we need to do now is come through the scenarios through to inject mocks and that should work. Let's take a look. The other thing that we can also explicitly pass through to inject mocks is the name of the scenario that we want to run as well. So, what we explicitly tell it to run, the default scenario for now. Even though it will implicitly run that if you have one scenario. If I want to do that, come here, should be able to load the page again. I have that exact same set of functionalities with which is cool. And add the widget, wait a couple seconds. And now it gives me a random widget. Yay! We've got that. Cool. [ Applause ] But that isn't particularly useful for anything other than a happy path. So, I want to just sort of disclose a little bit more about my application. Super-contrived. So, that's okay. In the template for this, actually, we're considering any widget whose ID is greater than 100 to be a dangerous widget. And we haven't actually seen this behavior yet. But we have written the code for it. We want to see it in action. And we want to write tests around it later. We want to simulate that. So, what we can do is we can keep our default scenario. That's our happiest use case for our application. And let's define a new scenario here. We can call it whatever we want. But we'll call it bad widget. And what we're gonna do here is we don't need to rewrite all of the mock for everything. We're only concerned when we get a new widget, what happens if it's a bad widget. All I'll do is write a new mock for the new widget. Forget again. And instead of responding with something that has a random ID, respond with something with an ID of 101. And we'll see what happens. We'll keep the delay in response code the same. Cool. So, what we've got here now is we just as I said before, we need to tell the inject mocks what scenario we want to run. And I can show you something that makes this a little bit cooler in a second. But for now, just run a bad widget. Come over here. It's going to get pretty ugly. Because a bad developer wrote this code. And, oh, no, we have a really dangerous widget now. And it doesn't look good. And something's gone wrong and we need to fix this bug. And I guess like obviously you could imagine this a more real world case. You know, what happens when the data is or what's going to be when you have a bug. But, yeah, I think you can sort of see what I'm getting at here. But one thing that is a pain is I don't want to have to go back into my code every single time I want to change scenario and tell data mocks to run this scenario. Fortunately, I've written a little helper function which is called extract scenario from location. What we can actually do is pass through the window.location object into it. And save that and come back into our code. And you'll notice when I click add new widget here, this will just run as normal through our default scenario. But in the browser, in the query string, if we specify a specific scenario we want to run. In this case, we have got bad widget. And we run this. Instead of getting our default scenario, we click add new widget. And I get that, and get a dangerous widget. And that's quite handy because now I don't need to go back to my code and work out what scenario I want to run. I could just run it straight from my browser and that's nice and quick and easy. But I'm just finishing off work. Unfortunately, I don't have it here to demo. A Chrome extension which works out what scenarios are available and allows you to focus between them between a nice pretty Chrome extension. That's quite cool. But -- let's just jump back here. And I guess I'm sort of shown you something that is quite handy for, you know, we're developing features, we're fixing things, we're improving things. And maybe the endpoint for these don't exist yet. Even if you wanted to, you can't even hit a running endpoint. We can mock out those responses. But I think like this, it can do a bit more than that for us. When we're running things like UI tests. tests like the integration of certain things that don't require Internet work activity. Or sort of like I guess third-party services that absolutely must be called. This is a really nice solution for that as well. Because you can run different scenarios in your integration tests and you don't need to hook up anything else into it. Obviously tools like Cyprus also have fixtures that you can run and you can have mock groups for that. Which is really cool. And I guess if you're leveraging that, there's no need to leverage this. But sometimes it is nice to just leverage one set of mocks. Like, for instance, go back to my code real quickly. We've got all of our mocks in this main.ts file. But we can extract that into a separate mock file so we're not polluting our bootstrap code here. And you can share the set of mocks between this and your UI test as well. But that's obviously entirely up to the developer what they would like to do for it. So, I guess I have been talking a little bit about the things I think that really are great about this. I guess there still are some things that this is lacking. Because we're intercepting the HTTP requests before they go out of your browser, nothing appears in your network tab. Which is a little bit of a pain if you want to debug the order in which requests were executed in. And a load of other stuff like that. So, I think that I probably still need to add some logging middleware into that. Or accept a pull request if anyone is interested in that. It's probably quite a good one. Things like simulating paginated data. I know a lot of the other sort of competing things also do that. And it doesn't have GraphQL support yet. I would love people to test. Enif one person were able to go and have a look at this, I think it's a great way of handling this sort of -- this sort of way of being able to develop code. It's really quick and it's really easy. And it stops you needed to rely on either someone or yourself writing a working endpoint or even just the pain of having to write pages and pages of JSON just to get you mocked up and running. I guess, just concluding, this isn't a silver bullet solution. There are tradeoffs. At the moment, you can't ensure that the mocks that you're providing are the right type that your endpoint is providing. I'm also working on something that will take in something like a swagger or RAML specification to ingest that and ensure that the mocks you are writing get those specifications. Which is pretty cool. But as I said at the very beginning of this, I really do thinks that a stagnant topic. Almost everyone I speak to when I ask them what they do for working locally, they either pull data from staging or prod or they'll use some JSON-based mocking solution. And I still don't think that we're quite there yet. We haven't really progressed in the ways that certain other facets of web development have been progressing this decade. So, I guess I just think that it would be really cool just to get more involvement in this problem space. There are some useful links at the end of this talk. There's a few underlying libraries that I really leverage And I wouldn't be able to make this possible if it weren't for that. I'll put out the slides on Twitter and all of that. But, yeah. That's basic will it, basically it, guys. Thank you very much. And please clap and cheer very loudly. [ Applause ] >> You can carry on, because I think that is definitely one of our first. I don't think we've had a baby up on stage before. Give another clap. Thank you, Dave. [ Applause ] So, up next here we've got offline first in Angular. And next door, profiling Angular apps. We are going to try to do this change quite quickly. So, see you back soon. . . . . . . . Offline first in Angular Marta Wisniewska >> Hi, welcome back. How are you all doing? Everyone still awake? Yes? Okay. So, next up we have Marta who is going to be talking to us about offline and Angular. Let's hear it for Marta. [ Applause ] MARTA: Hello, AngularConnect. Can you hear me? Can you see my slides? Everyone? Great. So, it means that we can start. So, hello, everyone. My name's Marta. I'm from Poland. And today I will be talking about the topic that's offline first in Angular. And before I start my session, I have a question for you. So, how many of you have ever heard about PWA? Good answer. So, the introduction, I can skip some of the slides. So, it's very great. And my second question is, whoever did PWA? The answer in Angular? Maybe? Good answer, yes. So, if you're using Angular, it's very easy to create your basic PWA with basic PWA features. Because you can apply a simple one comment, this is ngAdd, and a lot of it is required to be at PWA, it will generate automatically. And it's very simple. Especially for the -- where you have a static data in your app. And the current way of your data is the way this is converted into the web app in the progress web app. Today I want to talk about manages data in your app, offline first, that allows you to store your data locally and synchronize it with the backend automatically. And it's also a good way to improve performance of your app and user experience. And a few words about me. So, I'm from Poland. I live in Warsaw and work for a company called epoint. This is a software house. And we have focused on financial and eCommerce sector. And eCommerce is in PWA. And I'm working on the prompt in Angular, Sparta cuss. It's written in Angular, and it allows you to create components and new features necessary for eCommerce. And it's open source. And you can find a code on GitHub. And I'm part of PWA. And my journey started a year ago when I was writing my master's thesis. It was web apps and hybrid apps. And then I started a project on PWA Fire. We created open source resources, labs and tools that allows you to create PWA easier and to embed practices for web apps. And I'm a huge fan of community. I'm a member and organizer at Google Developers Group Warsaw. And if you have never heard about these groups or you want to join these groups in your city or host an event, see me after the presentation. I would love to help you. And this is the plan for us today. So, at the beginning I will introduce you into the offline-first approach. I will tell you what is in general the strategy. I will show the advantages of this approach. And next we will go to the offline storages. This is a key point to understand this approach. After that, I will show you a pouch DP. And you can store with data locally in the browser on the local side. And then synchronize with the backend. Next is the action model. This is a way to increase performance of your app. And the next pointly show you apps that are already creating this approach and with PouchDB. I want to show you this offline first approach. But I also want to show you what a big impact developers have on human lives. And today, stress and negative energy has a big impact. And maybe sometimes if you had this in the picture, that something happens too many times you. And regardless, and again and again. We notice. Or maybe sometimes feel good, but then it's better. And then you feel unstable, and you feel unstable, I don't know, like this. Or even a simple small things that frustrate you. Typically loathing, morphing like this. So, as you can see, the sadness, the negative emotions are really important today. And a bunch of scientists did research on human brains. And they were trying to find for certain how to make people happier. And it was surprising because they discovered that the only one way to make people happier is create fast and stable apps and use offline first. And what's in general offline first? So, it means that being offline should not be an error or condition. You know that, but maybe not from web apps, but from native apps. If you're you're juicing Spotify and you cannot track music. You can look at the list. And if you have it again, and all the clients are synchronized and you see the data that is changed. If you're using Slack, the desktop version, and you're offline, you are able to use this app. You are not able to send messages. But your app is still working and you're informed about the offline state. So, what do we do in web apps is that we start out with data locally on the frontend side. We cache it and show that to the users. And at certain times, we synchronize with the backend and store the data and fetch new data. So, from a developer's perspective, you need to write an app that has -- that has no Internet connection. So, I really like compared to mobile first. So, for mobile first, you start implementation for small screen. And after that, you need to enhance it for bigger. And here when you start an implementation for offline state, and then you can add more capabilities to your app to make it more powerful. But you need to be sure that your apps work offline. And there's a lot of advantages of this approach. And the first one is quite obvious. We can get the apps that are being able to work offline. But there's more. You're able, for example, to create faster user interfaces. Because all your cred operations create and are moved locally on your device in the browser. And we store data off of the user interface and apply option model. Which is really great because of performance. The next point is about creating better user experience. Because your user can use your app all the time. And you can be informed about the state of your app, of the network. So, it's very cool. And then last point, so, you can benchmark network requests. You can look at the backend periodically versus all the time. So, it can save bandwidth and also improve battery life. And there are golden rules of offline first approach. So, the first one, we should use local data whenever it's possible. So, you can use HTTP requests to get network requests and you can store it locally. And you have a few possibilities to do this. For example, you have cache API, index database and other offline storages. The second point is about storing separated user interface from data. And I suppose that you already do this in your app. If you're not familiar with this offline first approach. It's just easier to manage your data and your logic in your Angular app. The next point is about storing the data of your app locally and then remote. Remote if it's possible. The user can pick up wherever he left off. And the last point about testing. So, you should make sure that your app works perfectly in the scenario. And sometimes testing apps can be difficult, but it's really important to remember about. So, now about offline storages. So, I think it's a key point to understand this offline first approach. so, this is basic storages. And I suppose that you already know that. It's already very common. So, for example, storage and local storage are external storages that allows it to store data in your browser. And session storage allows you to store data for the duration of page session, including increased search of the page. But local storage allows you store your data even if you close and you open your browser. And they are really common. But they have downsides. For example, you need to serialize. And to serialize your data. They're asynchronous, so, can block your app. And doesn't have support for web. Talking about Webb SQL. So, WebSQL is asynchronous, it's got callback, but it doesn't have support for web. So, there are alternatives. So, you can use, for example, fire system API or fire API. They support web worker. And file system API doesn't have much power outside of Chrome. And it's sandboxed, which means that you can maybe fire XS. Fire API is a little bit better because of browser support. And in the first step, Fire API, and the list API. But particularly in our offline first apps and PWA we use index database and cache API. And index database, this is document database that allows you to store parts of the end value. And you can store different types of data. It can be strings, blobs, JSONs and so on. And it's the greatest one because of the support for web browsers. And in cache API, you can store parts of requests and response that represented HTTP requests and HTTP response. And you can take those that contain any kind of data that is over HTTP. And what we do in offline first is that all necessary files that are static that we need to -- we need to cache and fill out work for your offline, restoring cache. But for all other resources, we need to use the database. And JavaScript libraries that are wrappers for indexed database. Indexed database can be complex for some cases. And it's more developer-friendly that allows use to use this indexed database. Today I want to focus on PouchDB. But there are more solutions. For example, Dexie. js, Jsstop other or localforge. And as you can see, it depends on the browser. And they are set per origin. And you can use quota manager that allows you to check how many quota is already reached. And I highly recommend you open Dev tools and check to see what you store in specific types of storages. Here, for example, is Twitter. Twitter is also a progressive web app. I think it will be a key for you to understand what can you keep and store in this kind of storages. So, now let's talk about PouchDB. So, PouchDB's open source JavaScript library that allows you it store data locally and sync it automatically. And this is what I said before, that the server wrapper for indexed database. And this is the basic architecture that you can use in your Angular app. You have frontend side and backend side. And the frontend side, you have PouchDB. When you can store your data locally. And you have backend side where you can store data remotely. This is CouchDB. And CouchDB, this is document database that is very similar to the MongoDB if you ever use. And what we do in our frontend apps, we store data locally. And then we need to send it to the backend side. So, the backend of our application. And if anything changed on the backend side, and it pushed changes to the frontend side, and you can subscribe these changes and react in a proper way in your app. So, now it's time for more practical parts. So, let's suppose that you have app -- Angular app generated CLI basic and react. And then we want to make it work offline. And then manage the data that is offline. So, the first step, we need to cache data that is static. And for me the easiest way to do is to just to apply this comment. This is ngApp PWA. But if you apply that, a lot of things will happen and you will generate basic files that even if they are different, and even if you build it and you store if on your own server, then your app will work offline. And the next step is that we need to manage dynamic data in your app. So, we need to add to your app, for example, PouchDB as a wrapper for your database. And there are a few steps to apply this PouchDB. So, you need -- it needs to, as usual, have npm package. You have two options. First is PouchDB, the whole package. And the second option is a smaller package only for the browsers. And if you want to install other dependencies, like a database, I recommend the second one. And the next step is the installation of PouchDB server. Because you need to serve your local data in your app. Then you need to serve it. And if you want to apply it in your app, you need to use this -- the last comment. If you want to add it to your file, you need to create a local database that says PouchDB. After that, we need to hook it up on the backend for application. And you can use method sync. And we need to add to the database and configure it. So, you need to set the configuration for reputation. And in this case, you can see the directional organization. Next step is as usual you need to implement your operations. The basic operations to manage the data in your app that get pushed, delete, types like that. And the last one, sorry for the forbidden word. You need to subscribe the changes in React the proper way. Depends on what you want to do on these changes. So, now let's talk about option model. So, the option is the way to render a portion of your app via a route as a static render page. And it allows it to increase user experience by rendering static pages that you can return to the user very quickly. And from practical perspective, this is the -- there are minimal HTML in JavaScript and CSS that is required to power the user interface of your app. And on the right side you can see an example. This is how it looks. It is just a wrap common for all pages. And you can use schematics in Angular for the app shell. And we need to make the app shell and add. The first is client project, the name of your project. And the second one is the name of your universal app or server app. So, if you generate it, a lot of things will happen in your project. But the main change will be in your JSON file in configuration. So, you received one of the targets regarding to this option. So, next point is building. So, we need to run ngRun command. And regardless of your environment, this is part of production. An ID test. In my test I created a simple Angular app. I built it and deployed it as usual. And after that, I added option model, this app, and deployed to a another host. And I did a test. I refreshed this app ten times and here you can see the visual effect. That is on the right side. When you have the app with option model, you can see that you refresh it. So, you get the view very quickly. This is good. This is how option works. Here you can see performance result tests. So, can you see this five metrics? Load time, byte, render, first content, index. And the value for this test. So, as you can see for open of these metrics, the difference between the values of over 20%. So, this is what you can achieve with the app refresh model. Now I will show you an example of apps that was created through this approach and PouchDB. So, this is really cool. This is open source software for developing for hospitals. It's great because you can take it into areas where it doesn't have Internet access at all and you can store health care data. And when you've got to the places where you have Internet access again, and your data will be synchronized for all your clients. And this is open source, so, you can find these up. It's really cool through daily life as a developer, for example. You can store it contacts, calendars and files and share it between your clients. And between server. And final answer is for storing budget data in your personal devices. And it's really cool for apps when you can store this data and then synchronize with other clients and other devices. I want to sum up some things. So, we were talking about offline first approach. And you can use in PWA. So, I highly recommend you do try PouchDB. And other wrappers that can help you to manage your data in your apps. And I want you to remember that it's not only about creating apps that work offline. But also it's a way to create fast and stable apps. And it's a way to save the world from sadness. And I also invite you to PWA and offline first communities. So, sometime sometimes maybe you have a problem. It's difficult to find a solution because it's not a huge community. So, here you can see two spaces. There are Slack spaces. Where you can ask questions and find people that also are working with progressive web apps. If you want to keep in touch with PWA. You can follow PWA Fire. And if you have questions, you can Tweet me on Twitter. And this is a great book if you want to use PWA with Angular. It was published this year. I highly recommend you use it. And thanks for having me. If you want to get the slides, there is a link. Thanks. [ Applause ] >> Thank you very much. So, next up we have in here the coming FAD: Future accessibility for developers. Next in track one, automating your Angular project with schematics. Again, we'll try to start quite quickly. Thanks very much. . . . . . . The coming FAD: Future of accessibility for developers Gerhard Boer >> Hello, welcome back. So, we're nearly at the end of the day. Before we go, you have one more talk coming up from Gerhard. The coming fad: The future of accessibility for developers. So, let's hear it for Gerhard. [ Applause ] GERHARD: Well, hello, welcome, everybody. I hope everyone has had an awesome day. I always get a lot of inspiration from all the talks at AngularConnect. And I hope I can add to the inspiration that you have. More specifically, about the coming fad. The future of accessibility for developers. First off, a bit about me. My name is Gerhard Boer. The lead frontend at avionics. I have an interest in accessibility. I come from the Netherlands and I play a little bit of rocket league in my down team. Nice. You can find me on Twitter where I Tweet about Angular and accessibility. So, for the coming 30 minutes or so, I would like to talk about the current state of accessibility. I would like to talk to you about how you can actually define accessibility, who it's for. And then go deep into the technology of accessibility. How it works under the hood. This will help create an understanding about the future of accessibility. Currently in the form of a specification called the accessibility object model. And close off with things you can do right now to improve accessibility in your application. First off, what is accessibility? How to define it? Most think of using a screenreader. Right? You can actually take this a little bigger. Think about accessibility, you can think about them in terms of inputs and outputs. A fully accessible web application can be used by any form of inputs. Maybe just only a keyboard, only a mouse, maybe only using your voice or using gestures in order to interact with the application. On the other side, we have the outputs where we can have a screenreader-like voice over. Or a text-only browser with no colors to convey information about the application. Or maybe the user is visually impaired and needs to use a separate device, a braille reader, in order to read everything on the web. We can combine these technologies under the term assistive technology. Talking about assistive technology, any kind of input or output used to increase, maintain, or improve functional capabilities of the user. So, the goal of accessibilities is to get the web accessible for everyone. And when you think about who actually needs or could benefit from using assistive technology, you can imagine getting to the point where it's actually quite a big group of people that can use assistive technology. There's a term coined by Microsoft called inclusive design. You can check it out on their website. There's a big research plan and they thought about all the people that could actually benefit. They figured they could separate the groups into three different parts. First off, there's the permanent assistive technology users. They might have lost an arm and can't use certain keyboard configurations to interact with your app. People who are blind and need a screenreader or a braille reader. And people who are deaf and they need subtitles to know what's going on in the video. But next to the permanent group, might have a group that's temporarily impaired and could benefit from using assistive technology. Might have gotten an arm injury and gotten your arm a cast and can't use certain key combinations. Or something in your eyes, you can benefit from a screenreader for a short amount of time. Then there's also the situational group of people. So, this is just for very short amount of time. To benefit from using assistive technology. So, Microsoft has done a lot of research about this. And checked out in America. When you take all these three groups together, over 20 million people could benefit from using assistive technology in a web application. There's actually quite a lot of people that could benefit from the accessible applications that we write. Now, get into about accessibility and how does it work? The most important part about technology under the hood is the accessibility three. Accessibility three is build from a DOM 3. So, for almost every node that is in DOM, an equivalent node is created in the accessibility. I say almost every. For performance reasons, some DOM nodes that have no information whatsoever get omitted from the accessibility three. So, it's a technology that can perform a bit faster. How do we get information from the DOM into the accessibility 3? Well, the most easy way is to write semantic HTML. Don't use diff, use headers or footers or side bars. And these add more information to the accessibility tree and give them more power to interact with the application. Then there's a standard called ARIA, which standards for accessible rich Internet applications. You can add attributes to certain elements and make them accessible if they have no accessible information themselves whatsoever. Okay. You might be thinking, this is a bit abstract. Not really sure what's going on. Staring a bit into space. So, try it a bit more concrete for how that actually works. The browser might run into a tag, something like this. This is an image tag with a source attribute, pointed to an image on the server. And an alt attribute describing what's on the image. And through the DOM three into the official UI on the monitor. And con opportunitily, a node is created in the accessibility tree describing what this image is about. It might have a node-created image which has the name attribute field next to the information you have in your alt section. So, if you don't feel the alt attribute, you just have your image linked in the HTML, it means the name property in the accessibility does not get filled and the user with assistive technology has no idea what's going on on the page. Even worse, the Node might be admitted from the accessibility tree and they have no idea what's going on. So, have the images named so the users are aware of everything going on in your application. Then go a bit bigger, maybe some interaction in our application in a way of forms. Here is a diagram of the accessibility tree of a form. A slider and normal button. The name attributes for the radio button and the slider actually derives from the label elements that it's linked to. So, we need to use the four attributes in the label and have the ID for the value for the four attributes referencing the ID control. If you don't put the link, again, no information is added to the accessibility tree about what the element all about. And the assistive technology user is unable to know what radio button they're actually pressing. They just hear radio button and have no idea what's going on. So, the case for a radio button, you could have a state, selected or not. And it could have actions that the accessibility tree emits to the technology. The action press results in a DOM node. Specifically a clicking. And the slider, it could have a minimum and maximum value for the accessibility user. And it could have actions like increments and decrements which could result in increasing and decreasing in the slider. And there's probably, well, if you pull a specification closely, you have to implement the up key and down key in order to actually have those implemented in your application. Luckily a slider is a native component. It's a semantic component so we don't have to do it ourselves. But we'll get into something more specific later on where this could be a block. There's a button. The name gets usually derived from the value in the tag. And the action results in a click action on the button itself. Then there's something about ARIA. With ARIA, you can make any elements that is not accessible by itself get added into accessibility. Here we have an example where diff is in the box. But it's adds a check box. If you have no other way than to build something like that, you can use ARIA to make any element an accessible element. When we look to the complete picture, you have something like this. Our HTML gets built into the DOM tree. The DOM tree gets painted in, and it gets informed into the accessibility tree. The accessibility tree gets read by a native operating system API through assistive technology. And the API is different for each operating system. So, Windows, Linux and OSX all have their own implementation. The accessibility model has some ideas how to solve this. Then now I days we write a lot of JavaScript to have the applications more interactive. Comes in from the side, modifies the DOM tree, needs to be reflected into the accessibility tree and needs to be updated. This is currently a lot of work for the browsers and could be done a lot better. Although, if you look at this image, you might say, well, given a user all the crutches they need, right? They can get a route on the web and use ARIA to make the application a bit more accessible. Everything is fine. However, there are a few issues. First of all, ARIA is quite sensitive for developer errors. You need to have that relationship between a label and a control exactly right. If you make one typo in the relationship, the name attribute is not filled and the user has no information about that element. Furthermore, with the coming absence of WebComponents, we can add a lot of custom elements to our web applications. These are not semantic by themselves whatsoever. The browser cannot infer any intention about the WebComponents by themselves. And they need to add the properties in order to add the accessibility. And there are a few limitations. ARIA needs elements to have information to be added in. If you take a high performance UI that's built, you only have one element to match the information to. So, for this limitation, actually means the UI that you built is not added to the accessibility tree. And the assistive technology user has no way to interact with that application. Lastly, it's quite hard to automatically validate accessible tools. We have few static analysis tools. Which means that you can check if the relationships are set right. But it doesn't get the full information about the accessibility tree because it's not available that way in the browser. Enter the accessibility object model. In short, the ALM. Currently it lists a specification on GitHub. It's championed by people Google and Mozilla. And a lot of things added to Chrome, Edge nowadays. It's currently is still in development. Quite experimental. There have been rewrites and pivots. It's gone from one model, like a DOM to the AOM, to a set of changes that change didn't parts of the specification. They tend to do this in four phases. And into each one of the faces the goals and issues they're trying to solve in just a second. First off, what is the AOM actually apply to? We have the complete picture. The AOM combines the HTML, the DOM tree and the accessibility tree in JavaScript closely together. They can use JavaScript to interact with the accessibility tree. And give the DOM tree, for instance, more events in order to have accessibility users be more powerful to use it. Right? So, let's dive right in. A little bit deeper. First off, the four faces they're planning to implement in this specification. In the first phase, they want to add ARIA as properties. So, we don't have to use attributes at every single points. And we use JavaScript in order to add ARIA to our applications. First phase thinks about getting WebComponents up to date. They're not semantic and not good, for example, by themselves. The second phase is all about extending events to make the assistive technology user more powerful to interact with our applications and have the software and make it needing less work arounds in order to interact with the applications. The third phase is all about creating virtual nodes or virtual trees to get the element like the high performance graphical UIs. Maybe you imagine a streaming desktop software or a navigation software. And add accessibility to just one node. The final place is about introspection. Checking if it's done right. Also if we have the accessibility added to our application be correct and get all the information from the accessibility tree. So, the first phase, ARIA's properties and WebComponents. This is actually already possible in the ARIA 1 . 2 specification which is shipping in Safari today and is in a flag in Chrome. You can get a reference and directly apply ARIA attributes from JavaScript. This is already quite powerful when you do something like this, the edge case also gets projected into the HTML. And it's already solving the problem with IDs, right? You can put your reference, your relationship you find in JavaScript with your value of ID defined somewhere in components on your directive and make sure all the elements use that same property with which you have the relationship. However, this is not perfect. If you have a very large application, you need unique IDs for each and every element. Which is get a big hassle. It can make a long and unreadable ID. It becomes a lot harder. For this, the ARIA proposes going one step further than setting relationships just by strings. Namely by using the HTML elements themselves as a reference on the -- to create a relationship between two elements. These won't get reflected into the HTML. You don't have a need for many unique global IDs. And you can have everything set from your JavaScript, create a component or directive for this in order to create these relationships. This also solves a different problem with WebComponents. WebComponents have their own shadow route to be completely unique and separated from the global DOM. Here we have an example of a combo box which has an input inside the WebComponents. And the user is able to set the option list from outside. But if you want to create a relationship inside the WebComponents for something outside, impossible. The ID properties actually scope to these shadow. But if we can use the actual HTML elements themselves as a reference, we can use JavaScript to post through the shadow route, get a reference to the element and use it to create a relationship between our elements. This will not be reflected into the HTML, but it does result in the right information being added to the accessibility tree and thus assistive technology users able to interact with the application. When we go a bit further into WebComponents, like I said, they're not semantic by themselves whatsoever. Different browser sees a WebComponent like this, it has no idea what to put in the accessibility tree. Now the user of the web Components is forced to add these possibilities. Or the author is required to sprout new properties from inside the Webcomponent. However, when they change one of these, the author needs to write a lot of code. If they remove something, there's no default to fall back on. What is proposed is to add an extension to the current internals API for using WebComponents where we can use that internals property to add more information to the -- to add the ARIA information to the internal properties. This means there's a fallback. So, when the user of a web component wants to provide something, it's possible. And if he wants to remove it, the information is still in the Webcomponent to add this information to the Cascadia. But the author of the WebComponents needs to write a lot of code in order to handle all the situations. This is the part about WebComponents and ARIA properties. And we'll go further into extended events. Custom events for assistive technology in order to make it a lot easier for the software to interact with the application. But also forces developers, because we get more semantic events that you can use in the code. There's an issue with this. The user of assistive technology has no other way of interacting with the application other than the accessibility tree. When you get a specific Ent built for assistive technology, you can derive information about the user, whether or not they're using assistive technology and you can maybe do something with this information. But the AOM has a solution for this. First off, this is some of the events that this technology uses and the -- which meshes to a doesn't DOM event. These are what they want to add, scroll by page, increment and decrement. When they are added, the developers don't have to listen for the escape key. We can listen for the semantic events. And remove from the page, rather than reinsert. And to preserve the privacy of the assistive technology user, the idea is to actually throw both events at the same time. So, when a dismissed event event happens, the escape key is also thrown. You can listen to either of them. But the other way around, when you press the escape key on a current element, the dismissive element is also thrown. Which means if both events are thrown, the application is unable to determine whether this is from assistive technology or from a normal DOM node. So, this actually makes it a lot easier for assistive technology to interact with the application. Doesn't have to be a certain work around to interact. And we get a few more semantic, more readable events to listen to, which always works according to specification. Then I want to head into virtual nodes or virtual trees. I gave the example of a compass, having a high performance graphical UI. Very nice to build. Looks very nice on the screen. However, unable to be made accessible whatsoever. So, in this face, what it actually proposes is that from one certain point in the DOM tree, you can create an entire new accessibility tree. You can create this through JavaScript. And with this accessibility tree, the assistive technology user can still interact with your compass. And then it performs an action on a node, it results in a click event on the area of the compass just like if the user would have clicked their mouse on there. An example is a tic-tac-toe game that's on the GitHub specification page for the AOHM. I have it selected, and you can check in the accessibility tools and see there's an accessibility tool for the single element. Without using ARIA. It can be used. But there's only one element for that information. Unfortunately, this doesn't work at the moment. If you try to interact with the accessibility tree using assistive technology, Chrome crashes and it will just break down. I have had a bug report into Chrome, so, hopefully it will get fixed. The last phase is all about introspection. Validating if the things we added to our application to be made more accessible are done right. There are a few tools you can use today that you can add into the environment. For instance, Po11y, or koa11y or the XH environment. That's what they use. And this can do static analysis on your application to make sure what sure whether you're set right. And it doesn't give all the information, and maybe a bit late. In the build time. Just a week ago, there was an update Tweeted out for a code that we had accessibility rules added into the Code lyser plugin. And we have these from our IDE. This already safes a lot of hassle to validate it in the end. However, it's still not perfect. It's all about static analysis and having only the information available, either run time or rules. What is approached is to add a brand new API. Something called a computer accessibility tree API which allows us to gets the actual accessibility node information for a current element. Which means you can also use that information to walk through the entire tree. Or just check whether that implementation for accessibility hasn't been done right for that specific element. This information we have no access to at the moment. We can do static analysis. This will be a very powerful tool in order to create better tooling to check whether everything has been done right. It will be easier for us as developers to add the application. And you can try building your own screenreader just for fun. That's cool. What about support? Well, it's not that great. I mean, it's still experimental. It's still in development. The things that have been added like phase three and phase four are in Chrome behind a flag. And syntax is not the best at the moment. However, phase one, adding ARIA's properties is added in the ARIA 1. 1.2 specification. And having the ability to add more information to custom elements is being worked on since last July in Chrome. hopefully very soon we can actually use it in our day-to-day environment. So, what can we do now? What you can do is promote prioritization of access abilityin your company. Remember, at the beginning, take all the people in temporary situation and the permanent all together, in America, over 20 million people could benefit from using assistive technology and accessible web applications. So, actually a lot of people could benefit from having well done accessibility. Also, use semantic HTML. Leave the diffs to the side and use your NAV, your header, footer, these are all used to add more information to the accessibility tree. Giving the assistive technology something to interact with inside the application. Another interesting thing to do is to check your colors. Color blindness is a very large group of people. And there are a lot of tools online that you can use in order to ensure that your contrasts are right. But also don't only use colors to convey information. Red or green, make sure whether they're valid or invalid. Always have something available like an error message. For a vision impaired user who uses a device and maybe has no idea what a color is. One of the last fun things you can do is organize a screenreader workshop. Get a few people together. Download the manual for one of the screenreaders. Maybe VoiceOver, NVDA. And try to do something on the web or in the application you're building using only the screenreader. I guarantee you, it's quite an experience. Frustrating and fun, or a fun and frustrating experience. But I can wholeheartedly recommend it to experience what some people have to do on the web to get information. And close off with a quote, Tim Berners-Lee, and so-called father of the worldwide web. Access by everyone, regardless of disability is an essential aspect. Thank you. [ Applause ] >> Thank you so much. Okay. So, that's the end of the talks for today. But I've got quite a few things I need to share with you before you go. So, getting ready for day two. As you might have heard, there's actually going to be an international climate change protest happening [inaudible] -- so, you really have to make sure tomorrow that you bring and wear your lanyard to come in because we might not be able to let you in without. Also, make sure that you're here on time. There may be a bit of difficulty getting to the venue. So, we're starting -- we're open from 8:00. There will be some coffee and breakfast. And starting promptly at 9:00. But not yet. The fun doesn't stop yet. You're awake. Okay. So, next slide. There we go. After hours. So, kicking off now, we're gonna have some food. Thanks to or friends. And some drinks and Angular ale. Brought to you by [inaudible]. There's a live jazz band that will be kicking off as well. And back down stairs are our games and board games. And you can hang out there. At 6 p.m. we're gonna kick off here and start the lightning talks. They were really popular last year. Have a look at those talks. There's also a meeting downstairs, on the ground familiar, a walking tour of the area in London. And there's limited spaces. So, make sure you go and find -- [ Away from microphone ] -- signed up for that. And this is a bar crawl with Ed. Which is -- again, that will be downstairs at -- kicking off at 6:00 on the ground floor. But if you have signed up, you can join me and Pete. So, I think that's everything for now. And thank you very much. I hope you have a good day. And I look forward to seeing you tomorrow. Good night.

Channel: AngularConnect

Views: 4,084

Rating: 4.9200001 out of 5

Keywords:

Id: OBvWgu8jJXY

Length: 371min 42sec (22302 seconds)

Published: Thu Sep 19 2019