So we'll get started, first, thank you, thank all of you, thanks so much for coming to my talk, I really appreciate it, I know there are multiple tracks, there's lots of ways to spend your time, so I really do appreciate every single one of you for choosing to spend your time here. Thanks also to RubyConf, to all of our fantastic sponsors, and to the venue, I've been in LA now for about three years, I don't make it downtown a lot, LA is kind of like a weird archipelago, and when you're on your own little island you tend to stay there, but this is a fantastic venue, so thank you so much. Let's get started. I tend to speak very quickly, I'm working very hard right now to not talk a mile a minute, because it gets worse when I'm excited and talking about software engineering and Ruby and writing ethically and ethical programs, I think is really, really exciting. So if at any point I start going way too fast, feel free to make some kind of, yeah, thank you Michael, exactly, some kind of very visible gesture and I will slow it down, I'll also check in a couple of times to make sure that this pace is good. So I'm going to talk for about 35 minutes, so we'll have a little bit of time at the end for questions, if for any reason I go a little bit long, feel free to come find me after the show, I'm happy to talk about this stuff forever. So my name is Eric Weinstein, I'm a software engineer here in LA. I'm currently CTO of a little startup that I co-founded called Aux AUX. We are building auction infrastructure for blockchain technology, so a lot of price discovery, a lot of game theory, people sometimes in other programming communities will check in with me to see if I've sort of secretly gone crazy because I'm doing all of this blockchain stuff, but it really is fascinating and that's another thing I'm happy to talk people's ears off again after the show. My undergraduate work was in philosophy, mostly philosophy of physics, but also some applied ethics. My graduate work is in creative writing and also computer science separately. So ethics in software engineering has been on my mind for a while now. The rest of my information is in this human hash I felt compelled to make. So it'll be up at the end again if you'd like to get in touch. I'm Eric Q Weinstein, Q as in Q, Q-U-E-U-E. I guess Quebec is probably a better Q. So please feel free to reach out on Twitter, feel free to find me and I'm happy to have conversations. A few years ago I wrote a book called Ruby Wizardry that teaches Ruby to eight, nine, 10, 11 year olds. So if you want to talk about that, I'm happy to chat about that too. Oftentimes the good folks at No Start shall put together a discount code. So if you would like the book but can't afford it, please let me know. We'll make something work. This is not a long talk, but I still think we benefit from some kind of agenda. So we're gonna start with what it means to be good because it is a fuzzy idea, right, to say we should be good when we write software. Our software should be good. We're gonna look at three mini case studies in Roboethics and then three mini case studies in Machine Ethics. Roboethics concerns itself with humans being ethical when building robots. And I'm gonna be a little bit loose with robot and include program. So any piece of software or hardware that a human designs, Roboethics is about behaving ethically and having ethical considerations top of mind when building these machines. Machine ethics is more of a science fictiony field and we'll see why in a little bit. But this is more about how we design artificial moral agents that are themselves ethical. So if a machine makes a decision, how do we know if the machine is being good? How do we assess the ethical state of the machine's decisions? And how does that compare to how humans make ethical decisions? And then, as I said, we'll hopefully have a little bit of time at the end for questions. So please note, this talk contains stories about real people. No one who was injured or killed is specifically named. There are no images or descriptions of death or gore. However, there is going to be a lot of discussion of how software and hardware can fail and what those failure modes entail. And we're going to touch on some topics that are potentially upsetting for members of the audience. There are a couple that are medically oriented. So it will not hurt my feelings in the slightest if you need to leave. Do not worry about it, but I want it to be up front so that everyone is aware of the content and the stakes involved. So the stakes involved are actually quite personal to me. This is my son who was born in March. He was born 12 weeks prematurely. So we decided to skip the third trimester. I do not recommend this, but luckily there are, I think, kind geniuses is how we describe the folks in the NICU where he spent seven weeks, unbelievably hardworking, kind, passionate, genius people, his doctors, nurses, therapists, everyone who took care of him is phenomenal. He was 12, sorry, two pounds, 13 ounces. When he was born, it's a little hard to see. But if you see that black and that red wire, right below that is my wife's hand. He was about two hands full. So I also like this image and I will show this at every possible family gathering forever because he appears to not appreciate me taking a picture of him. If you're curious, he's wearing a Billy Rubin mask.  So he's wearing a mask to protect himself. I like to think of it as like a little spa treatment, but now for those in the audience who are concerned, do not worry. He is a happy, healthy, 17-pound, eight-month-old baby. Thank you. He is finally bigger than the dog, which is great. She is a Chihuahua mix, so impressive. Like I said, we are unbelievably lucky to have had the team that we did at Mattel here in Los Angeles. And I cannot overstate the unbelievable gift that was every single member of the NICU staff. But we think a lot about the people in the room. And we don't always think about the people not in the room. Everything from his heart rate to his O2 saturation, every single metric. Somebody wrote software or built hardware to measure it. Every treatment he required, everything from the way his food was administered required a machine to do the right thing. And it's easy to forget in the whirlwind of something like this, where you have a medical emergency, you have something very scary happen to you that there's a lot of hardware and software running in the background that is critical for maintaining people's well-being and their lives. And so this talk is in part about that. So, like I said, the stakes are high in more ways than one. And part of the fuzziness that I want to dispel early on in this talk is what it means to be good. There are a number of ethical theories. We're gonna be thinking mostly about and talking mostly about applied ethics in this talk, which is what to do in concrete situations. How to live ethical lives and make ethical decisions rather than talk about the abstract. What if this were the case? How would we behave? Imagine various thought experiments. So there are a number of schools of thought. I'd like to focus on three. The first is utilitarianism, the idea that we're trying to produce the most good for the most people, whatever that means. And you can imagine if there were some way to measure goodness and there were some way to figure out how much good each person has received then we could do some kind of calculus and say, great, this optimizes. This is the most good for the most people and this is what we should do. Clearly, there are scenarios where that is not going to work. There are also deontological ethical theories and these are rule based. You can think of the Code of Hammurabi, the Ten Commandments, Kant's categorical imperative, which basically say, we're going to have general rules slash laws and they're going to describe what we should do in broad circumstances.  Things like that. The middle ground that we're going to pursue in this talk, insofar as we talk about how to be good, is what's called casual history. Which is funny actually, because I think I looked this up earlier, those of you with broader vocabularies that I have might know that casual history also means sophistry, like things that appear to be informative but are not. In this context, what we're talking about is sort of case-based ethical reasoning. Extracting rules in sort of a deontological way, but from specific cases. Like what do I do in case A, B, C, all the way to Z, and sort of trying to abstract a rule system rather from there. So as you can see, I'm going to take something of a casualist approach. And I'm going to break one of my own rules briefly and just read this to you. For the purposes of this talk, being good means safeguarding the well-being of moral agents that interact with our software by deriving best practices from specific instances. And that's why we're going to look at these many case studies to figure out what we should be doing. So we'll start with Roboethics. And Roboethics, again, is sort of how humans are ethical when they design robots or design programs. And we're going to look at three cases, the Therac 25, the Volkswagen scandal, which Caleb mentioned in his talk, and the Ethereum Dow hack, which seems different from the first two if you're familiar with them. Sort of a financial thing rather than people's lives or health being endangered, but it is I think illustrative of the broad spectrum of ethical concerns that we should be thinking about. So the Therac 25, raise your hand actually if you're familiar with this. Okay, cool. So I will, please indulge me if you know this story because I think this one is important. The Therac 25 is a machine that's used to perform radiation therapy for cancer patients. It was designed in 1982, and it had two modes. One was to provide megavolt slash x-ray, which was often called photon therapy, and another, which was direct electron beam therapy. So two different modes. The earlier models had hardware locks and were thoroughly tested in terms of the hardware that was used. The Therac 25 gave up some of these hardware constraints in favor of software constraints, and so what happened was between 1985 and 1987, the machine caused massive overdoses of radiation for a number of cancer patients, and I believe six people died as a result of their injuries. So what happened here, right? We have a machine that has two modes of delivering radiation to ostensibly make people better, but it malfunctions. And it actually causes severe injuries and in some cases, death. The review at the time blamed concurrent programming errors. So we know that concurrency is hard, it is also potentially, lethally so when we get things wrong. What happened is it was possible that as a technician, if you selected one mode, realized you had made a mistake and switched to the other mode inside of an eight second window, the software locks would fail to engage. And the patient would receive a 100 times greater dose of radiation than was intended. And what allowed this to happen? As I mentioned, the hardware interlocks replaced software ones. So we now have a less robust way of preventing people from being harmed. The code was not independently reviewed. It apparently was reviewed sort of by the engineers on the team, but there was no independent third party review of the code involved. It was also written entirely in assembly. So we did not have any kind of high level language to help. The failure modes were not thoroughly understood, not just incorrectly programmed, not understood. And the hardware and software combination was actually not tested at all until the machine was assembled on site. So all of these played into the injuries and deaths that resulted in the mid-1980s. And the underlying bugs were everything from arithmetic overflows to race conditions to truly cargo-cultured code. Code that was just copied over from earlier versions of the machine, some of which did not work or do anything in the current machine. How is this speed? Is this good? Thank you. So what do we learn from this, right? We have a machine that is meant to heal people and does the opposite. Well, I think what we gather from this, we see a parallel between the medical profession and our own. And here there's a, in medicine there's something called a standard of care. That is the sequence of treatments that you're supposed to offer. They're sort of the bounds within which you operate as a fully trained, up-to-date medical professional. And deviations from the standard of care do happen. But generally speaking, when you hear about a malpractice lawsuit, it is because someone has deviated from the standard of care and caused injury or death. And in this case, engineers deviated from their standard of care. And we endangered people who depend on us. And in this case, deviating from the standard of care was not following best practices, was not testing our code, was not being 100% sure of the, in the hardware and off-boarding things to software because software is a self-problem, which as we know is not true. Our second mini test case is Volkswagen. So as Caleb mentioned, in 2008, Volkswagen vehicles were caught using what is called a defeat device. So the idea is that the vehicle will operate differently under test mode, then in real life. So you will have fewer emissions, different emissions, different behavior when the vehicle is being tested by regulators, then when the vehicle is out on the road performing in sort of quote unquote production, right? This, it's harder to quantify this one. As I mentioned, there are a number of, a concrete number of deaths with the Therag 25. It was clear exactly who was harmed and who was injured. Less so here. Certainly there was a lot of money that was spent, a lot of fines that were paid. Estimates are that this resulted in 59 premature deaths due to things like emphysema, COPD, general respiratory illness as the result of exposure to the increased fumes from the vehicles. Again, difficult to quantify, but certainly financial and human costs are involved. Now this was allowed to happen because everything from the speed to the steering wheel position to the ambient air pressure could be used to determine whether or not the machine was in test mode. And as software engineers, that sounds like a thing we should have, right? We have test, we have staging, we have production. We have different environments and the code is tested differently in them. And it may on the surface not sound unreasonable for someone to say, let's have a test mode or let's detect when the machine, when our vehicle is being tested. That in and of itself might not be bad. Maybe there's metrics we want to report back to Volkswagen. Maybe there's other things that we can learn from having the ability to detect when the vehicle is under test. But we have a moral hazard here of this quote unquote victimless crime that was not so victimless. An idea here is well, we don't want to have to follow a bunch of really stringent regulations. We're going to lose money for the company. We're going to have to do this and that. No one's going to be hurt if we just have lower emissions in tests. And we pass all of these regulations with flying colors. Everyone's happy.  So what I think we get from this one is that we must always ask ourselves what our code is going to be used for. And I think it's not only our right but our obligation to refuse to write programs that will harm people or other moral agents who interact with them. And we'll talk about this more later and what this means and how hard this can be. But I think the takeaway from this is that we have to be able as people who write software, who build things that people depend on, we have to be able to say no. And as Caleb mentioned, engineers have gone to prison as a result of this. For those of you who are familiar with the Goldman Sachs high frequency trading, debacle, stealing code can send you to prison back in the early days of cryptography. There were questions about freedom of speech because cryptography was generally understood to be a weapon, a sort of part of the top secret sauce that makes the US military work. And so there are always going to be powerful forces that tell us what we can and can't use software for. And I think we need to be empowered to disagree. This third sort of micro test case or micro case study rather in Roboethics concerns the Dow and the Dow existed in 2016. It was the first attempt at sort of a large scale, decentralized autonomous sort of venture capital vehicle. The idea is people put cryptocurrency, in this case ether, into the Dow. Members can vote on how those funds are deployed and sort of have this decentralized VC fund that can be used to fund various projects or initiatives. However, the problem was that there was a smart contract and smart contracts in Ethereum are code that are deployed to the blockchain, to the Ethereum blockchain and are sort of elaborate state machines. They can receive input, they can change state, they can provide output. You can think of a sort of a vending machine is the classic example. I tend to think of things like escrow, like I wanna sell you something. My money, sorry, my item goes in, your money goes in. Once both parties have fulfilled their obligation, they're exchanged, right? Dissintermediation, decentralization, these are the utopian themes involved. However, because of a bug in this contract, 4 million ether, which is about $70 million at the time and as of this morning about $840 million were siphoned out of the Dow. Out of the smart contracts, out of the organization. And this reminds me of a panel I gave a talk on a little bit ago to attorneys who are trying to figure out how blockchain technologies work and what the liabilities involved are. And one attorney raised his hand and said, right, but who do I sue? Do I sue the software engineers? Do I sue the hacker? Do I sue the people who are, do I sue the miners who are confirming these transactions and quote unquote shouldn't? This is a theme that's gonna come up more and more as we get further into the talk. But liability is a huge concern. Now, this could happen. I actually just realized I have the remote, which is why I've been moving around and making the videographer. But thank you so much for dealing with me moving around and wondering. The Ethereum smart contracts are Turing complete. So they can do anything a Turing machine can do. And that means that there are lots of smart contracts that you can implement, that do nothing, that throw errors, that just spin endlessly and waste all of your funds for computation, which in Ethereum is called gas. This means that there are state machines within valid states that are now possible. And the particular bug in this smart contract was a re-entrancy bug. Effectively, the order of two lines should have been transposed. Rather than perform a transaction and then update state, we probably should have updated state and then performed the transaction. But because the transaction was performed first, it was possible to repeatedly siphon funds out of the contract. And this is something that could have been caught again with more robust third party testing, with more comprehensive, maybe gear improvers or more powerful programming languages or tools that would allow us to say, this is actually, this contract can get into a state that we don't want. Now, the result was not as bad, quote unquote, as certainly as the Therag 25 people dying. Not as bad as people losing money and potentially getting sick and dying from the Volkswagen scandal. But at the same time, this one bothers me in some ways more than the others. Because I don't think we learned anything from this one. The result was a hard fork on the Ethereum blockchain. The people who said, well, that's the cost of doing business. That's how things work. People steal your money sometimes. Continued on Ethereum Classic, ETC, ETH is the ether you probably, if you are familiar with, Ethereum know now. And that was the result of making things right. So now there are two parallel universes. There are two ethers and people who held both got more money. Now certainly people who invested money in the Dow lost their money. But I think there was no serious introspection that resulted from this. And I think sort of what Uncle Ben has said, and RIP Stanley, I definitely did not finish these slides this morning or yesterday, with great power comes great responsibility, right? And I think we are obligated to make programs powerful enough to do what they need to do and not more powerful. We don't need to write programs that can do things just because, or maybe we'll need that functionality, or maybe we need turn completeness. I think we're obligated to make programs that do what they do and do not have the ability to do more. I think that one is probably a little bit more contentious. So those are our three case studies in Roboethics, how we should think about writing software and what should kind of cross our minds. Who's going to lose money? Who's going to jail? Who's going to be harmed or potentially killed if I make a mistake? Now we're moving more into the realm of machine ethics. And this got kind of heavy, so I put in this cartoon pirate robot to lighten things up a little bit. It's an illustration from the Ruby Wizardry book. So the three sort of case studies we'll look at here are a little bit more hypothetical, although they rely on technology that exists now. And these are facial recognition, the use of police data in predictive policing and autonomous vehicles. So as I said, there's going to be sort of a theme here. It turns out Minority Report, or Philip K. Dick more generally, just kind of predicted all of these things to some extent. So there's going to be a lot of Minority Report references in the last half of the talk for those of you who are not familiar with machine learning. The idea is simply producing programs that can do work without being explicitly programmed. It's effectively pattern recognition. You say, this is a picture of a car, this is a picture of a car, this is a picture of a car. And then you say, okay, what is this a picture of? You're teaching the machine in some sort of way to replicate human learning to derive a generality from a series of instances. There are a number of different ways of doing machine learning. We're going to talk mostly about supervised learning and in particular decision trees and neural networks. So here's our first one, this is Apple's Face ID. And what I think is interesting about this is not simply being provided access to something based on our biometric data. But what does it mean for the machine to recognize us, right? What does it mean for us to provide our biometric data to Apple, for Face ID, to have our faces and information about us sort of derived from photographs if you're using Google Photos, tools like that. It was fascinating to me that Google knows what my baby son looks like because it has sort of gone through and tagged all these photos. It's like, I don't know who this is, but this is all the same guy, which is fascinating and horrifying to me. And again, this is the sort of obligatory minority report reference where there's that scene where John Enderton goes into the mall. He's recognized by his retinal scan and receives these ads that are tailored to him, right? So who owns these biometric data? Do they belong to us? Do they belong to Apple? What happens if somebody uses my biometric data or it's sold to a third party? What happens if there's a colossal privacy invasion? I almost said piracy invasion because of the robot earlier. Which is much more entertaining. Above and beyond this, what does it mean for the machine to make decisions using my data, my face, my fingerprint? It's really interesting, and I think some people will, or I at first, kind of glossed over this thinking, well, how is this different from the machine accepting my password, right? Hash is the password, looks it up in the database, the hash is matched, great, this is you. I think the difference here, above and beyond ownership, above and beyond the potential for identity theft is that the machine is making a decision in a very rudimentary way. And we don't know why it makes the decision that it makes. We know that if our password is rejected, something's wrong. Maybe there's something going on in the server. Maybe we typed in the wrong password. But there's a deterministic, modulo network hiccups and other things, reason for this. There's not necessarily a deterministic reason why the machine would not recognize us. Is it because I turned my head to the side? Is it the lighting? Is it because the machine has been trained on some data and the machine does not recognize faces that look like mine for some reason? Men versus women, adults versus children, people of various backgrounds, ethnicities, races. And when we entrust machines with the power to do human things, to decide, to recognize, to permit and to deny. We're implicitly giving their actions moral weight. And I think this is the beginning of machines having moral dimensions to the choices that they make. Now, I wouldn't say that any machine that we've created so far is sentient, right? It's not able to make decisions in a classical sense. It's not able to, I would not ascribe an inner life to any machine that we've created so far. But we're getting there, at least in a sort of superficial way. And it's something we don't, I think, treat carefully enough. This is how you know you've made it, by the way, when you get to reference one of your other talks from a talk that you're giving. So this one, again, is referencing the Department of Precrime from Minority Report. And I gave a talk at Euroclosure, I think a little over two years ago, that focused on the use of policing data in Los Angeles and in LA County. And Los Angeles actually has a very robust, very complete set of open data for all kinds of things. And one of those data sets has to do with police investigations. And the one I looked at, effectively, was who got pulled over? And when someone was pulled over, were they arrested? And I used a couple different machine learning approaches here. And this one is a decision tree. And decision trees are nice because the machine can tell you, effectively, why it's chosen to do what it's done. There are some relatively straightforward ways for it to kind of divide the tree at a certain point and say, hey, the most information gain is here. I can actually make two relatively equal sized blobs and then we'll keep doing it. We'll keep doing it. We'll keep doing it. So unsurprisingly, the machine looked at the data, built a decision tree, and 77 or 78% of the time, it was right. And it learned to be right by saying, is this person African American? Is this person a man? This person should go to jail. It's very obvious. Now, I think that this is something that is surprising to people when they hear this. You think about this passionate machine making recommendations. The DOJ and the NIJ have launched initiatives to explore what they call predictive policing, which is much closer to this scary idea of pre-crime. And the idea here is to figure out who is likely to commit a crime, who is likely to commit crimes again when it comes to sentencing.  And it's particularly dangerous when we say, I didn't do this, a human didn't do this, this is a dispassionate machine. The machine can't be racist, so this is the right answer, and this person goes to jail, and that's the end. Now, in the decision tree example, the machine can sort of explain its decisions. But you can imagine something like a support vector machine, a neural network, a much more elaborate black box machine learning algorithm. That cannot, there's no explanatory power here. Again, biased data, you get biased machines. And the worst, most dangerous part is people saying, humans didn't have a role in this, so this must be the right answer. Absolutely not. The machine has learned from human decisions. And just as Conway's law tells us that organizations are constrained to produce software that mirrors their communication structure. I think we are, when we're using machine learning models, predictive models, we are constrained to mirror the biases present in the data. Now, I don't know if this is a law already. I'm going to call this Weinstein's conjecture because apparently I can cite my own talks and name my own conjectures and laws. If Weinstein's conjecture is a thing, we'll call it something else. We can, actually we can take a vote later, because I think there are cooler names than Weinstein's conjecture. Anyway, so the critical thing again, bad enough to have a bias in, is this a tumor or not? We would like to be right when the machine is making this decision. But if it's who gets a loan, who goes to jail? Who gets arrested? These are critical problems that we have to confront, before we can allow machines to act as moral agents. The last one here, self-driving cars, autonomous vehicles, probably needs relatively little introduction. Many of you are probably aware of the high profile deaths associated with Uber and Tesla when these machines fail. And the question again, calling back to the attorney in the blockchain discussion, is who's liable, right? Is it the machine? Is it the car that's liable? Is it Tesla or Uber or Google? Is it the people who drove around in the car for hours and hours and hours and taught the car how to drive? It's very unclear who's at fault. And again, the machine is not able to explain to us why it shows to do what it did. And this is really dangerous when we, again, start trusting machines to make these decisions on our behalf. And again, if you remember, when I already reported there's that scene where he slides into the car and the car's self-driving down a highway. So again, I don't know how Philip K. Dick predicted my entire talk, but here we are. How many of you are familiar with the trolley problem? Cool, so I won't spend a lot of time on it. The idea is you see a trolley heading to hit, I don't know, five people, you can pull the rail switch and it will hit three people, do you do it? From a distance you can't tell anything about these people, even if you could, you wouldn't know much about their lives, their behaviors, who is good and who is not. It's a hard enough problem for humans. But now the trolley problem is something that we're asking machines to solve. Do we swerve to avoid an obstruction, preserve everybody in the car, but we kill somebody on the sidewalk? Do we try to figure out the number of people who will be harmed or injured or the gravity, the severity of their injuries and make a calculation based on that? None of these sound like good answers. When I say how do we teach our robot children well, this notion kind of calling back to moral hazards in the Volkswagen scandal, how do we perform mechanism design? How do we design these reward functions so the machine does what we want and does not do what we don't? This is not an easy problem. And again, who is ultimately liable. I think the takeaway here that machines actions are not only imbued with moral dimension when we get here, but that need for explanation is critical. And the capacity to accept blame. We have to know why the decision was made and whose fault it was. Because in order for things to function legally, in order for us to learn and move forward, we have to be able to say, this is the reason this happened. And here's what we're going to do to fix it. I think that that explanatory power, the capacity to accept blame is critical in the sort of humanization of our robots. Actually, just a quick thing. I meant to ask this earlier and I totally forgot. How many of you have some kind of formal computer science education? And here I mean a bootcamp or a CS degree or any classroom experience. Great. Keep your hand up if there was an ethical component to your coursework. Somebody made you take an ethic class. OK. It looks like a little bit less than half. I think we have to, have to, have to start teaching ethics in COPSI courses, in universities, in bootcamps. And we're getting out to the TL, DPA, which is what I call the too long, didn't pay attention. So if you were not paying attention for the first part, that's great. That's totally fine. We can get it all in this one slide. We have to have a standard of care, and that means best practices. We have to have a structure or framework for writing software. When we are writing programs, we have to know what's acceptable and what's not. We need the right to refuse. And here I'm thinking of a Hippocratic oath, something like that, where you make a promise, and this is true for attorneys, for doctors, for engineers, for all these professions that we pretend to be. But then we're like, oh, we don't need to be licensed. We don't need to take an oath. We don't need ethics. We can sit down. We can do Git push Heroku Master, and our software is out in the world. Not to pick on Heroku, Git push anybody master. And I think we have to imbue these artificial agents as we build them and make them more complex with the sound moral bases that we lay out for ourselves. Because it's one thing for us to figure out how to be ethical when we write programs. It's another, once they're out in the world, doing their own thing, whether they're smart contracts, neural networks, autonomous vehicles, robots, what have you, have to have some way to say, here's why I chose to do this, here's the reasoning, who made that decision, and here's how we learned from it. Now I had not really intended for this to turn into a call to action, but the recent election cycle has got me all amped up. I'm very excited. I think because people can be injured, people can be killed when we screw up. And people say that. I can't tell you how many places have worked where the answer was, hey, don't worry about it. We had an outage. Nobody's dying. Nobody's going to jail. Sometimes people do die. They do go to jail. People are harmed when we make mistakes. What I think we need is we need an organization as software developers to fight for these things. Now, as you can see, I'm a white man with a beard and a wedding ring. So if I walk into a conference room as CTO, senior engineer, whatever, and I say, we're not doing this. It's not ethical. And we'll have no partner. There's a non-zero, a reasonable chance the business will back off and say, OK, let's at least talk about it and figure out why. But if I have just come out of a boot camp, if I am not a straight white man with a wedding ring and a beard, if I am someone who has substantially less social capital, less privilege, less power in the organization, and I say, I don't want to do this because I think it's unethical. And the answer is, do it or you're fired. And you do have an elderly parent, a new baby, someone who's ill. This is the first time you've actually done a career change, and for the first time financial stability is on the horizon for you. And the difference between you having a semblance of a life and not is taking the stand, the pressure is unbelievable to write that invasive code, to share that third-party data, to gloss over some error in the training data because it will probably shake out with enough training. And what I think we need in the absence of ethical organizations inside of our computer science programs and inside of organizations, I think we do need those. But we need somebody like, I don't know if it's a union, I don't know if it's the EFF, somebody we can go to and say, I need you to have my back because I am not going to write this code. And it is not acceptable for me to be fired for taking the stand. Now, I'm happy to talk about what that means, what that looks like, who does it. But it reminds me of a quote by A. Lee Vizel, who's a Holocaust survivor. And he said, we must take sides. He said, neutrality helps the oppressor, never the victim, and silence encourages the tormentors and never the tormented. And that has a lot of, I think, parallels in the current political climate. And I'm happy to talk about that later too. But most importantly, what that means is, if we don't say something, we agree that we don't need these guidelines. And I think we have to have to have them. So that's all I've got. Thank you so much for coming to my talk. I really do appreciate it. And the question is, how do we operationalize all this in our code reviews, in our day-to-day work? I do think that having an explicit code of conduct for the organization is a great place to start, where someone says, here's, we have RuboCop for linting. We have these ways of building our process. Here's our continuous delivery pipeline. But we can also say, this is how we address these questions. I think having a wiki, case studies, being able to anonymize data and say, somebody came to us and said, you know what, they were not acceptable writing this ad. When I worked at Conde NAS, there was an ad called the guillotine. It did what it sounds like. It was extremely hard to deal with. I started running an ad blocker, so I didn't have to look at it, even though our team was tasked with building it. Even these trivial questions are things that you can build into a wiki, build into an internal document. And someone can say, I don't feel comfortable. What do I do? Now, again, it's tough when you have it within your organization, and you don't have a third party that has your back. But I think that's a great place to start. That was an excellent question. And I have settled, for now, on the Legion of Benevolent Software Developers. So sorry, yes. The question is, what is the name? What name are we thinking of for this group that will defend our rights to not write unethical software? And I've, for now, settled on the Legion of Benevolent Software Developers, but I'm always open to input. And if we build this thing together, I think we can arrive at something great. All right, I think that's all the time I have. Thank you so much. Please come find me if you have questions. Thank you.


I'm David Fowler and I'm Stefan Halter. We're going to talk about what's new in SignalR in.NET Core 3.0. All right. So here's our agenda. We're going to start off by doing a small version of what is a SignalR, a one-on-one for those of you who are familiar with the platform. We'll talk about our new NPM organization. So we made a small change to where we store the package in 3.0 and that's important. We'll talk about the new feature client-to-server and server-to-client stream that's a pretty cool feature that we have a demo for in 3.0. The most after-feature in SignalR has been reconnects. If you use SignalR before, you know it's a source of pain. So in 3.0, we have a new feature called automatic reconnect. We have a demo for that as well. That's definitely a show in a few seconds. If you're familiar with Dynacore 3.0, we have a feature called server-side blazer, which is powered by SignalR as well. Finally, if you want to scale your application in Azure, use the Azure SignalR service. All right. So what is SignalR? SignalR is a client, we call it a persistent connection abstraction. What that really means is any place you want to use WebSockets or get live updates, you could use SignalR instead. It's an abstraction because we have multiple transports backing the actual connection. It can be long polling, service and events or WebSockets. So why not just always use WebSockets? Some clients aren't capable of doing WebSockets. So depending on your client and service capabilities, you may have to downgrade to different transports. So let's talk about how each of those work before we go into a quick demo of how SignalR works. So for long polling, the client sends a request to the server-side saying, do you have data? The server will respond after some time with I have data or I don't have data. The reason it's called long polling is because that poll could last for up to a minute without getting data. The server will reply with data and then after the server replies, the client sends a new request, asking for more information. So this is better than regular polling. Better than, yeah. It's better than asking every second, but it is still not sufficient as other transports. So server-send events or SSE for short, is an API in the browser where you send a request using an event source API. It's long-running request and the server can send responses over that single request. So it's really good for a server to client throughput but it's not great for a client to server. That still requires a request per message. Then the big Kuhuna is WebSockets. So you send a single request that says, I want to upgrade this connection to WebSockets. Then the server says, okay, cool. Let's change protocols and then we have a single connection that goes server-client-client server over the whole lifetime of the connection. Do I have to pick which one I want to use? The signal are smart enough to pick the best transport based on your server and client capabilities. We call that process negotiation. Now we're going to do my classic favorite signaler one-on-one, which is a chat program. So in case you want to do replace Slack or Microsoft Teams, here's your end. So we're going to start with having a file new project. Here's my Hello World project so far. I already prepared since we don't have much time in this demo. So I used a new client-side package manager to add signaler. So I can go to, sorry, that was kind of fast. So again, right-click the project file, add client-side library. So this is new? This is new and VS 16 point, I don't know the version 16 or something. I can choose a bunch of different providers. So there's CDN, JS, a popular CDN library manager for JavaScript packages. I can get it from disk, I can use JS deliver or unpackage. Unpackage mirrors packages in a CDN format from NPM. So I can use that to search for, for example, Microsoft signaler. So it's not at ASPnet signaler? It's not and that was our old organization. We want to be where the other packages for Microsoft were. So we went to the same org. You can see here Microsoft has a bunch of packages. I can search for signal R and if the internet is willing, it will work like a charm. But if it isn't, I already prepared the application because this could happen. All right. So that works, trust me. Normally, you would see the files and you could select which one you want from the NPM package. So quick segue, this is the older version of the package. It's under ASPnet slash signaler, and the version is 114. Going forward, it is under Microsoft slash signaler, and it was published 15th, well, I should reflect, but probably today right at some point. So for 3.0 and on all words, you want to use the Microsoft org on NPM. We didn't duplicate the old because we still have people using the old package. We haven't figured out what to do there yet. So that's the current state of the world. All right. So that was not interesting.  On the server side, I'm going to wire up signal R and L. So I'm going to wire up my already built chat hub. I actually have a copy, because I'm lazy, the endpoint. So there's a new feature in ASP.NET Core 3 called endpoint routing. I'm going to wire up signal R to those routes. This is different from 2.0 where we had an app.U signal R, there was a middleware for signal R in the pipeline. App.U signal R is still there, but it's deprecated now. Can you see that, that zoom in? It's in the tool tip deprecated for those who can't see the small text. I was zoom in, but I don't want to risk it. So now instead of calling use signal R, you do use endpoints, map hub chat. So I'm mapping the chat hub to the chat endpoint. I'll hit F12 to see the actual hub. The hub is very simple, it has the hub is where all the clients connect to, it's the central hub on the server side. There's a public method called send. What send does is send will send to every client that's connected. It's all because I'm sending to every single client. I'm calling this method, passing the message that was sent to me, some kind of an echo broadcast to all clients. On the JavaScript side, I have a simple page here that has some pretty fancy UI, a text box, a button, and a UL for messages. This is the height of my UI skills. Not even bootstrap. Not even bootstrap. Wow. I have a clean area to write some code from scratch. Boom. Wow, that was fast. Yeah. So let's go through the code very quickly. I'm creating a hub connection builder, passing in URL slash chat what we had on the server side. Whenever someone calls send from server to client, it will call this function and then we'll create a new entry in the list of messages. I see it's not case sensitive, is it? It is not because that would be user hostile. All right. Now, we use vanilla.js the library to warp the event. So whenever someone clicks on the send button, I'll add an event listener. Whoa. Whoa. IntelliSense. I'll add the click handler to get the text from the text box and then send it to the server side. So calling invoke here ends up calling invoke, passing in send is calling the send method. All right. Those map. Let's run this. I hope it works the first time. All right. To demo signal art, I need at least two people, otherwise it's kind of boring talking to myself in the same window. So I'll talk to myself in a different window. So hello. Yay. Works. All right. All good. Cool. Working fight. All right. It's working. All right. Good. Awesome. All right. So that was your Signal 101. If you want to get started to make a Slack competitor, our Teams competitor, that's how you get started. All right. Let's continue from there. That was a quick demo, I hope. Let's talk about how Signal are broadcast to different groups of clients. Just know we did a broadcast. So going to everyone currently on the hub. You can also go to a single user, and the user may have more than one device. So I'm David. I may have an, well, we have Anthony here. So this is Anthony. Anthony has a desktop, an iPad, or a tablet, or a surface, maybe a surface, and a phone. And we can target all of those devices, or we can target a single device. Or we can target arbitrary groups. So imagine you had a chat application that had chat rooms. A group could be a different chat room. So I can send to everyone, to a user, to a connection, or to a group. So one client can be in a bunch of groups, right? That's right. So I can be in two chat rooms. I can be in many groups. So Stefan will show us his super awesome Uber demo that shows pretty much all the new features. No pressure, Stefan. Yeah, thanks, David. No pressure. So, you know, since David showed you the sample that you all already saw, I was tasked with creating a new sample. So one of the big new features in client-to-server is client-to-server streaming in SignalR 3.0. So we have another Visual Studio instance, which is a SignalR 3.0 sensor demo. So to show you what client-to-server streaming looks like, we're going to have a C-sharp client. So this uses a SignalR client very similar to the JavaScript one that David just showed you in the chat sample. But instead of showing you chat and allowing you to chat, what this is doing is this is publishing sensor data to the server. So because I'm on David's computer right here, and we are short on time, I'm going to have to describe this part of the demo to you because I don't trust myself to type it accurately. But you have what you saw before, hub connection builder. And in this case, it's connecting to a sensor hub. Just like on the JavaScript client, we have this builder pattern. So you create a hub connection builder. Pay no attention to the man behind the curtain. What's that region? All right, it's actually not that complicated. But we're not doing anything too tricky. We're just trying to have a no-op callback. Hide it, hide it. Sorry, I should have skipped it. So after we start it, this quickly goes into using our client-to-server streaming ability. So you'll notice that we have a single method call. So in this case, we're calling a hub method called publishSensorData. And then we're passing as an argument an iasync and neural. So this is kind of new. It's in .NET 3. And then we also have async iterator support in C sharp 8. So this is pretty cool. What it allows you to do is, every second is creating a new iasync and neural item to double from 0 to 10. And then it publishes it to the server. And unlike a regular iasync and neural, where you might call like, and neural will get next and it's going to block an entire thread, this is all async. And so it's very scalable. What is the await using var? Ooh. Some new syntax there. That's a good catch. C sharp 8. So our hub connection has an implements iasync disposable. Not very cool. So not only do we have a using that scope to the method, so that means that it gets disposed from the method ends, since it's await using, it's calling disposeAsync. So that allows us to, without blocking, without wasting thread pool threads, shut down our hub connection. We hit blocking threads. Yes, especially in ASP.NET. So if you ever have .result or something, try to figure out how to do less of that. So we can quickly take a look at what this is doing on the server when we call publishSensorData. We're using another C sharp 8 feature, which is await for each. So we can take this iasync and neural, you just saw us pass it. So it gets nicely serialized, deserialized in real time as new data arrives. And we can asynchronously iterate over it. So again, like this await for each is basically calling a numerator moveNextAsync. It's very efficient. And then we can use our sensor collection service. So if you go and look at our startup class here, this is just like we call addSignalR, we have this service here, that basically allows us to publish our sensor data and then we can subscribe to it using getSensorData. So I can show how you can stream server to client. So this is already a feature in SignalR 2x, but you can combine these together nicely. So inside of our web app, we are going to have this chart, which is going to show us the sensor data. And we're going to use streaming to download the stream. So here we have this chart div in our body and we're going to use new, I think it's iasync await. And we're going to update this object of XYZ sensor data. So again, hub connection builder, connect to the same sensor hub. And then after we await and start the connection, we try to see like what are all the sensors that are connected to our web app. Once we get, this is an array of strings, all of our sensor names, we call subscribe to sensor for each sensor, call getSensorData. And then this is returning like an RXJS observable. We didn't pull in the RXJS library. If you did, you have a lot of cool helper things to do like filtering and things like that. But what we're worried about here mostly is every time we get a new sensor, a piece of sensor data, we're just updating this object and that's going to ultimately update a line chart. And one last thing is you'll see that the subscribe to sensor we're calling connection.stream instead of like connection.invoke or something. So this is like when you're doing server to client streaming, you call that stream API. And then this is returning the same iasync and new rule that we published. So without further ado, we're going to control f5 this and we're going to quickly see a browser pop-up without any sensors. But fortunately, we already have the folder where we had that program. So yes, we have that async iterator that's giving us random numbers from 0 to 10 every time. So we're going to run sensor with a name X because we're using the first argument as the name of our sensor. And we're going to run a sensor with name Y. We can call the sensor whatever we want. As long as it's XYZ, it should end up showing up on this chart. And we can go full screen here because this is one of the few single-art demos that doesn't really need side-by-side. If it was side-by-side, all the browsers would be seeing the exact same sensor data. What is that data? Random doubles from 0 to 10. Like an earthquake chart. Yeah, it's pretty fancy. That sensor is kind of getting crazy, but it was really simple to write. So that was my favorite part of it. That was pretty short. So what happens now, though? Actually, there's a slide for this. In practice, I missed it every time. So we just did server-to-client streaming as well. But what happens if the connection... breaks? And there are a lot of reasons this could happen. You could have some mobile client going through a tunnel. You could be redeploying your web app. The quick way for us to sample it here is just to close the server. We can pretend we're redeploying. If we go back to our app, you'll see we're no longer getting new data if we were to restart the server with CTRL-F5, nothing's going to reconnect. So people who might be used to previous versions of SignalR might expect this graph to start moving again. But SignalR core, up until 3.0, had no way to automatically reconnect. We told customers that write a closed event handler, dart the connection manually. But that ends up being a lot of code. I don't know about you, but when I write a lot of code, it's more likely that I'm going to write a bug. After, like you said, it was highly requested, we added some automatic reconnect functionality. In this part, I'm going to try to kind of write. So let's see if we can pull it off. Hopefully it's simple enough that I'll be able to do it. So to make the sensor automatically reconnect, we go into our HubConnectionBuilder and anywhere you want, like with URL, it's like, you know, you can chain it. We can call with automatic reconnect. Why is it not on by default? We're worried about making breaking changes. We don't want people who expect the client to disconnect suddenly after they upgrade to SignalR 3.0 to start reconnecting without them realizing anything's going on. So you have to specifically opt into this, but we try to make it as easy as possible. So we have this with automatic reconnect extension method. We're going to use the default overload, which we'll try to reconnect as soon as the connection goes away, and then we'll try again after a few delays. If you want to control the delays, you can pass in your own array of time spans, or if you want even further control, you can look up iRetryPolicy on MSDN. So we would like it if that was the only thing you had to do, but there's one or two gotchas when reconnecting. One thing you'll notice is like after we connected here initially, we called publishSensorData. As soon as you reconnect, any ongoing method calls end. So what this means is that you need to, if you want to continue publishSensorData, you need to call that method again. This part, I am going to write an un-reconnected handler. So what this is, is hub connection now has a reconnected event. So if you use with automatic reconnect, it will call this once the client successfully reconnects. And it's exactly what we did after we called startAsync. We just called publishSensorData with our async iterator. And that should be enough to have the sensors automatically reconnect. Now we have to do something very similar in JavaScript. So again, to save me some typing, we're going to just pass in with auto-reconnect. We're going to use that method on the hub connection builder. And with the client, with the chart client, we ended up having many streams. So we called getSensorData for each sensor. So there were two that we just used. So for each of those sensors, we're going to want to call getSensorData again when we reconnect. So JavaScript also has a reconnect event. It's a very similar pattern. And just like we did after we connected, we can call getSensorNames and then for each of them, subscribe again. One thing that you'll notice, I kind of glossed over this really quickly in the C-Shark client, is that we actually pass in a connection ID every time you reconnect. What this is indicating to the user, because you can actually, if you want to, have a hub connection dot connection ID, and it will be the same value. So it's not strictly necessary, but it's more like we're trying to highlight that this is a brand new connection from the perspective of a server. So onConnect is going to be called again. You've got to resubscribe to any groups that you want to be called. You need to start all your methods. The one big thing that you don't have to do again is you don't have to resubscribe to any onCallbacks. So now that we've enabled, that's all you need. That should be everything to do reconnect. Magic-reliable signal interconnection that lasts forever. One thing you'll notice is we only made client changes to do this. So we can leave the server running once we get it running again. So then, we now have to restart the .NET clients because they stopped because we didn't have automatic reconnect earlier and now we do. I'm going to make sure they're both stopped when they're like recompiling or whatever. So we're going to start our X-sensor. We're going to start our Y-sensor. And so far, it's what you saw before. So nothing too surprising. But the question is, what happens when the connection is lost? The earthquake hits. Right. So right now, we have three single-hour clients connected to our web app. We have both sensors and then we have this web page that's showing us the data. So we have the X-sensor to client and they all need to restart. So we close it. Cross your fingers. It stops. It flat lines. Everything's dead. Yeah. All right. We control F5 again. Don't pay attention to the new tab because obviously that's going to work but apparently the sensor's reconnected and okay, it's still flatlining. There might be a delay, hopefully. There's a delay as it's trying to reconnect. I'm suspecting that we're in a 20-second delay right now. So we're going to go back to the old tab and we can see some of the logs from this. Did we refresh this? Did I save? That would be funny too. Did you refresh it? Did you refresh that old page with the new... All right. So normally we would try to be seeing reconnect events. So let's look at this again. All right. So that's just the favicon. That's the only error. So this should have auto-reconnect because I save. So we're going to do this one more time. If it doesn't work, we're going to pretend. There's a word before. Yeah. So you can see the sensors are trying to reconnect. That's what those logs were. And then, boom! So now you can see it went from flatline to the lines are moving again. I don't know if you can see the screen. So we killed the client and the client's flatline. That's kind of a visceral. All right. So now we're going to go back to David to talk about the SignalR service. A little bit of time left to talk about the service. All right. So you finish your application and put it to Azure Now. And the issue with that is that you need to scale both long-running connections and short-lived connections in the same application. So what the service was designed to offload your concurrent connections to a different service so your app can scale the web traffic independently. There's a free turn in the service. You can get up to 20 connections and you can pay for more scale if you want up to 100,000 connections. And in 3.0, we actually improved the experience where you add a package to do so before it was 2.0, it's 1.0. So a huge improvement. Two is too difficult. So before, in the olden days of hosting SignalR, you would host everything in an app service or an IKS cluster and you would put your pages and your hub in the same application. All good and fine. The issue is you're trying to scale the long-running connections in the same app as your short-lived connections and that can get kind of tricky. So the SignalR service, you add it and what happens is it moves the SignalR traffic off to the service side and then your app can batch handle connections over a different pipe than the actual ingress traffic. So you're turning a thousand connections into five as an example. And I'm going to turn Stefan's demo into a connected SignalR service application with just a single line of code. One line of code. Are you sure it's only one line? Maybe. Are you going to get stash pop and hide some stuff? So the first thing you do is you install this package that you installed previously. It's going to be RTM today. People have to wake up on a different side of the world to upload a new package. So I have Microsoft address SignalR 1.1.0 preview, blah, blah, blah, blah. It'll change to something else eventually. I think 1.1.0 RTM will ship today. And then in my start-up class, I can do add SignalR add address SignalR. And then that's the whole thing. So how do we prove that it works? Okay, so what is the service doing even actually? Web scale. Web scale, okay. Independent scaling. Yeah, still works, right? That's all good. Did our client just reconnect? It did reconnect. If you look at the log it started off at look at that. It started at local host 5000 sensors and it went offline, came back online and ended up going to SignalR Hello Service, SignalR Service, Client Hub, blah, blah, blah, more things. So you had a web app in two sensors that were connected to local host. You typed in .addAzureSignalR redeployed and then everything just kept on working using the service. So it's going from my client to Azure to my machine, which is super inefficient because it should be both in Azure but in Azure it's way more efficient. And you don't have to like scale up your Azure app service just because you have like 10,000 concurrent connections. And actually I believe the conference is using the Azure SignalR Service to show notifications on the actual stuff below this video, right? That's pretty cool. Awesome. I believe we have to take questions soon or something. That's the thing. That's the whole thing. Are you ready Scott? Hello. That's live television people. We're trying to raise a lot of money for the kids here. Sorry. That's okay. So a couple of questions and one of the questions I've actually had and there's at least three or four different examples of this on Twitter are people are saying they want to understand if they're using Blazor and WebAssembly, how do they call SignalR? Are they using because they're in WebAssembly, they're on the client side are they using the .net SignalR client? Are they using JavaScript? I think it was even so sassy as to say I challenge you to do this in Blazor without using JavaScript. So what's the relationship between Blazor WebAssembly, SignalR, WebSock? Go. Super interesting question. That you have no doubt thought about deeply in the past? We have. So there are multiple. So currently I believe there's a third party SignalR client written with JS interop to make a .net based client to make an end to end scenario work, right? That's what we don't want to ship that. We actually want to ship the foot on that client as it is today running on my machine compiled into well, I guess interpreted in the browser. The only thing that we would shim is WebSockets. So you shim the transport layers. So you need to shim HB client WebSockets to use fetch or WebSockets in the browser. But the actual C sharp logic from the client should run in the browser like a normal C sharp library. But not yet. So far it doesn't run and you have to kind of use JS interop to talk to the JavaScript SignalR client from C sharp which feels kind of insane because you're going like C sharp interpreted called into JavaScript to do stuff and then getting events about the C sharp and then like the whole end to end. So what would you recommend to people today as we release .net 3.0 who are enthusiastic about Blazor because you've got Blazor client side you've got Blazor server side, you've got SignalR who are excited but they don't know what the correct way to go is. So for server side the situation is a little bit unfortunate because it's not very efficient. You could use the C sharp client but what will end up happening is you will spend an entire connection, TCP connection per client, per browser client you'd have one per server. But one, one WebSocket client on the server side per browser client which isn't super efficient. Right, so right now a server side Blazor uses SignalR. So it's kind of bridge the server and the client. But adding extra connections between the server and the client is a little unnecessary. So we're looking at ways to optimize that. So today is inefficient and you can use the client on the server side but it's not great. We're going to talk about that I think like before we ship FIVO. Okay, so there will be guidance and prescription on how to do that? Of course. Okay, another question. Here's an interesting one. So with SignalR help understand how Kestrel would work. If you were just doing Kestrel and you know, can Kestrel talk SignalR and handle lots and lots of connections or do you need to have Azure or IIS or something big in front of it? No, so Kestrel works fine. It's actually probably more efficient than all the other servers that we have for SignalR and it can handle a ton of concurrent connections. We're not the best at memory but we actually made a ton of improvements in for connections over WebSockets to reduce memory footprint and improve throughput. And there is a Redis, you know, horizontal scaling so you can scale that way but I would say like how many connections are supported will depend on the activity of the connection. Oftentimes you're bandwidth limited with these SignalR applications. And memory. Memory, yeah. It depends but like those broadcast scenarios can easily consume a lot of... CPU. Yeah. Here's an interesting one. With the focus, the new focus on GRPC... Oh, wait for this one. Are there plans to have SignalR work with GRPC Stream? What is that relationship? Very early. What is GRPC Stream for those of us who might not know? So... It's funny. So GRPC supports streaming. Is it funny, David? It's pretty hilarious. Funny ha-ha. I knew it was going to happen. Funny like... Uncomfortable. No, but what is GRPC Stream? GRPC supports streaming from client-server and server-to-client. And server-to-client. It supports both directions. They're picking back on top of HTTP request, which is interesting. And it pretty much... Let's just say the feature of SignalR, except ours is a little bit nicer because we were kind of like... We used ISAC in the removal on both sides so it kind of looks more native. But the feature... The feature set is pretty much the same feature set between both things. Except for SignalR, of course, also provides the PubSub kind of groups and podcasts and things like that. Yeah. All right. So there is overlap, but there's no current thinking around merging the two features. Maybe that's a conversation that you might want to have on Twitter. I would encourage everyone to go to Twitter and crush at David Fowle and friends with questions about SignalR because he has nothing better to do today than answer these questions. And I want you to go ahead and just absolutely flood him. Thank you very much, David and Stefan.


Hello and welcome to the session. I am Deepika here. Let's discuss the question, find the distance between the following pair of points minus 5, 7 and minus 1, 3. We know that the distance between any two points Px1, y1 and Qx2, y2 is PQ is equal to under root of x2 minus x1 whole square plus y2 minus y1 whole square which is called the distance formula. So we will take the help of this key idea to solve the above question. So let's start the solution. Let us 1, 3 be the given points. By using the distance formula, distance PQ is equal to minus 1 plus 5 square minus 7 square. So this is equal to 16 plus 16 which is equal to 4 root 2. So for this question is the distance PQ is 4 root 2. I hope the question is clear to you. Bye. Enjoy yourself.


Good morning, and welcome to the seventh meeting of 2018 of the Environment, Climate Change and Land Reform Committee before we move to the first item on the agenda. I want to remind everyone present to switch off mobile phones and other electronic devices as these may affect the broadcasting system. The first item on the agenda is for the committee to consider whether to take items 3 and 4 in private. Are we all agreed? We are—agreed. The second item on the agenda is to take evidence on the reasoning for a breach damsfynt gan y dwyn niadau yng Nghymru, Twannodivell, Menedig, Scymd Llywodraeth, Ymysgolun, Llywodraeth, Gwymd, Deirchwyn, Llywodraeth, Saathedr, Llywodraeth, Zheleu'r Fyrde, S하겠습니다w, Llywodraeth, Rwyfyr, Pwrdwyllwyr, Llywodraeth, Fyrd-Gwyllwyr, Llywodraeth, S yardım, Llywodraeth, Llywodraeth, Llywodraeth, Sâtodol, Pymblidan, Llywodraeth, Llywodraeth. I thank you for the opportunity to speak today. At the end of 2017, I became aware of an inconsistency between the Electricity Works Environmental Impact Assessment Scotland regulations 2017 and the EIA directive. This inconsistency required applications for our section 36 variation Mae cyfnod o'r edrych arlau isen nhogwrs ymddirionedd mewn bwrdd e-AIA yn caffndag o rhai fe ar fynd ymddyllai ar ddiwrnod ar y ddym machech. Mae ysgol wedi cael ei g wedi gwaith a'i gael arweinyddai ar y tre Groes, ac oherwydd a'i ddweud gan y cyfnod o'r ffwrdd e-AIA. Fe fydd yn rhoi ddweud gan e-TAE yn cael eu cyfnod o'r dyfanyddiaeth. that is necessary to amend the 2017 regulations to bring them inline with the EE directive and minimise the unnecessary regulatory burden on ministers, stakeholders and developers. Those amendments will help to ensure that further delays to offshore wind farm developments is avoided without compromising our commitment to safeguarding the environment. Llyfridogol a'r byffredig sydd breddai lluniaethion ar gyfer gyfer henchau Llyfridogol yn ddim o ddwylen ffarn y tro, oherwydd, ychydig i wneud, gweld y proses EIA, gwaith y blynyddol i amser unrhyw hwnnw, ac yn hwnnw i angen i gydagiaethau clinogol, mae gynnwys ar gyfer 50 ar gyfer mwy o ddysguol, a lluniaethau unrhyw hwnnw i ddwylen hwnnw i ar 30 sphysgol o 4 mwy o dd耶chydd, a lliniaethau rhaid i ddim yn mynd i ddefnyddio o'r cydwyr. Onw、 dweud y Llywodraeth 28 i fy ngyf bod lleiwyr sy'n gweithio'r cymryd yn ei wneud i gydagrathu'r cynllun o'r edrych ac mae wedi gweithio'r cysylltu'r cymrydosodd yn ei wneud i gaeliasu a'ch hefyd i gaeliasu'r Cymru gyda Gwyl Wagdoniamol Gwyl Wagdoniamol Gyda Gwyl Wagdoniamol Gyda Gwyl Wagdoniamol Gyda Gwyl Wagdoniamol Gyda Gwyl Wagdoniamol, os yw lleisio'r ni ddigonwch a the EIA directive, and as part of our drive for continual improvements for efficiency and robustness, we'll undertake a review of the 2017 regulations and the marine works EIA Scotland regulations 2017 to ensure they are consistent with each other, as they are also both applied to the same sector. I'm happy to take questions, convener. Thank you minister. Just a technical and context question, ministers under section 36 have no legislative competence under section 36, just administrative ability to give consents for generations over 50 megabytes but megawatts, computer strikes again. I take it therefore the only way in which this sort of thing can be sorted out with as a conflict is not by looking at the electricity act but by looking at the bringing the regulations together in one interpretation. I believe that that is the case, but I will check with my colleague Joanna Dingwall in case there is any misunderstandings there. I believe that that is the case, Mr Stevenson, and you are correct in that assumption. You said the only circumstances in which an EIA wouldn't be required would be generating capacity. Unrhyw ddiwedd yn gydag, myfyrdd, yn gweithio. Pryddo'r cyfrifoedd i ddefnyddio'r tectnologiaid o'r cyfrifioedd y ffordd ddaeth i gynnwys hubau eu hunain. The best example being if a turbine was upgraded in terms of its power output, unless improved otherwise yn gael ei wneud ymddangosgwrdd mewn cyd-dwybr! Felly dweud i'r ddweud o gydych chi'n siŵs o'r gerchawr.  Ond bynnag, mae'r yanlış cychydig o gwybatraeth mewn i gwybodaeth i gyfweld y teimlo i gail gwybodaeth fel oedd mae'n gylwgr Modnol iawn i'ch gwybodaeth i gyfweld yr unig. Mae'n ei gwybodaeth sy'n gwybodaeth yna, maen nhw eich gwybodaeth i cychydig y tarbwyr, gallwch arwad, y hublaeth, y tawr mewn, oherwydd ystafell ar mynd i gwybodaeth i cysylltu ac unig o gwybodaeth o ddim y tŵr, koelwch yn ddych chi'n wneud. Those changes are more likely to require an EIA because of its significance, depending on the scale of change that was involved. Certainly, a change in turbine's power output that we do not believe would have an environmental impact, so that situation is cited. I did not mean to present it as the only example. One thing that I understand that is normally is that a significant change in the power capacity of a turbine byddai'r unig o'r hen Witness yw ydy'r union iawn, a phas sy'n rhoi ei ddod y lleolau i ardal i dдаeth i ddod yn y cyflusio penderfynu. Felly'r gwaith m sicknessu yn ddrill iawn yn ddylai'r lleol iawn yn hynny. Mae hyn yn bryd yn ni'u dalion iawn yn ddegi dddangosach ac mae ein gwaith i ddaeth yn ddyneb i ddegi ddegi ddegi ddegi ddegi ddegi ddegi ddegi o'r turbine, ond mae'n gweithio'r engin o'r turbine, ond mae'n gweithio'r power output o'r wind, ond mae'n gweithio'r power capacity o'r site. That can arise for a number of reasons, because we have changes in terms of the financial environment for wind farms, both onshore and offshore, that is necessary with either reduced subsidy or more competitive environment for subsidy. They need more powerful turbines to be able to be competitive in terms of winning that, but it may also be the case that turbine manufacturers have moved on their technology and no longer making them less efficient turbine units, and therefore they have to use the available technology that is there for them and have to replace like with like, with more a more powerful outcome from the point of view of generation capacity. That doesn't have in our view, or at least to date, we've not seen evidence that has an environmental impact and is likely to be something that wouldn't require an EIA under the change that we've made. Okay, thank you. A number of members want to come in. Mark Croskell to be followed by Claudia Beamish. Yes, thanks, convener. Perhaps just further to that minister, could you say a little bit more about the screening process, because there is a determination of what is a significant environmental impact or not, which then triggers an EIA, so what actually happens before something is ruled out of a full EIA process? Obviously, it would depend on whether we had an application for a variation, so it assumes that a developer comes in wishing to make such a variation and then presents a scenario whereby they want to change perhaps the turbine to more powerful output. That would then be notified to stakeholders who would then have, I'll just check with colleagues just the length of time that happens. 20 days, convener, to respond to that, to indicate whether they felt there was a material change that did have an environmental impact. Unless there was such a representation made, there may be 50 bodies potentially that would be notified of that and therefore have the ability to respond to that. If they didn't respond or responded that they were happy or content with the change, then 10 per cent could go forward without an EIA being triggered. I'll just check with colleagues of Gail Holland, convener, if I'm going to bring in Gail Holland. Where it's thought that there may be an environmental impact from one of these changes proposed, it would go through a formal screening process at that stage under the EIA regulations and at that time we would consult with a number of consultation bodies to get views from them on whether they thought the change proposed would cause environmental impacts. On the basis of that consultation, we would form a screening opinion, which would either screen it into the EIA process if there were significant effects identified or out of the EIA process if there were no significant effects identified. Just about data. Obviously, data is very important in terms of understanding impact on potential species but also informing the industry and informing the wider sectors as well. So I'm just wondering, does this have any bearing this change on data collection and the requirements for data collection? To my interpretation, no. If there was an environmental impact identified, for example, then we would clearly want monitoring of any impact of a project on species that would not change just based on the turbine. Having changed, for example, it would still be a requirement for the project. It may well be that projects that are applying for a change in turbine have had an identified environmental impact. It's doomed to be, obviously, through the consending process, one that can be either managed or is acceptable, but that doesn't mean that it's stopped the requirement for monitoring simply because they've not had to go through any EIA for the change in the turbine. So I want to reassure the member that if environmental impacts are identified, then they will still need to be dealt with in the same way as previously in terms of monitoring requirements and mitigation when it's required or there's planning conditions, they will still need to be fulfilled. Claudia Beamish Thank you, convener. Morning minister and colleagues. It's a follow-up question to that. Is there any guidance that is publicly available in terms of any list of what is unlikely to be necessary to go through the environmental impact assessment process? I just think that this might, in some ways, reassure stakeholders and anyone with an interest. I don't believe that there's a published guidance yet, but I'm going to be asked Gail if she can respond to that, convener. No, there is Scottish Government guidance in place, but it needs to be updated to incorporate the amendments to these regulations. The guidance that's in place was published in 2015, and it makes very clear that any application for a variation is only appropriate if the proposals are not fundamentally different in terms of scale, character and environmental effects. That's the kind of wider guidance, but it is required to be updated to include the changes brought about by these amendments, and that will be done in due course. So nothing specifically yet, convener, from this, but it certainly needs to be updated. In response to Claudia Beamish's valid point that when that is updated, you're right to the committee minister detailing the exact position that we will then be in. Very happy to give that commitment, convener. I think that's an entirely sensible suggestion. Do any other members have further questions? Do you wish to add minister? No, just to stress that other than to stress that this has done in exceptional circumstances, I very much respect the 20-day rule and the reason for it being there. It's done reluctantly in this case, and hence my desire to offer immediately to Pugh before the committee, because I was aware of the great importance of trying to maintain such disciplines. So reassure the committee that it's not going to be a general rule, is very much the exception to the rule. Okay, minister. Thank you for your time and that of your colleagues today. At its next meeting on 6 March, the committee will consider the carbon accounting scheme, Scotland amendment regulations 2018-SSI 2018-40 and its work programme. The committee will also consider draft correspondence to the Equalities and Human Rights Committee and its approach to an inquiry on the marine environment. As agreed earlier, we will now move into private session and I ask that the public gallery be cleared as the public part of the meeting is now over.