All right, I'd like to thank everyone who's joining us today. Welcome to today's CNCF webinar, I'm Jeffrey Sika, I'm a senior software engineer at Red Hat, and I'm a cloud native ambassador. I'll be moderating today's webinar. We would like to welcome our presenter today, Baruch Setagorsky, head of DevOps Advocacy and Developer Advocate at JFrog. A few housekeeping items before we do get started. During the webinar, you are not able to talk as an attendee. There's a Q&A box at the bottom of your screen. Please feel free to drop your questions in there and we'll get to as many as we can at the end. This is an official webinar of the CNCF and as such is subject to the CNCF Code of Conduct. Please do not add anything to the chat or questions that would be in violation of that Code of Conduct. Basically, please be respectful of you and all of your participants and presenters. With that, I'll hand it over to Baruch to kick off today's presentation. Thank you, thank you very much, Jeffrey, and thank you for having me to CNCF and thank you for coming, all of you. So today, we're going to talk about continuous updates and what it is, how it's different from any other kind of continuous things and how we go about it and how we don't go about it. So before we start talking about continuous updates, I would like us to think about a couple of things that we take for granted. And first would be why at all we update software? Obviously, there is some software which doesn't require updating. And that's an example of a BC for probably most of you know, for those who don't, BC is a command line calculator. You type two plus three, I get four. And obviously this kind of software is not updated very, very frequently. You can see here the history of updates. Frankly, I have no idea what those updates are required for. It's not that the basic rules of math changed from 1991 to 2000, but even considering those updates, you can see that it wasn't updated for 20 years and it's probably okay. There is nothing to update there. But obviously this kind of software is an exception. Most of the software is updated, updated frequently. And I would say that it updated frequently for too many reasons, too many reasons. The first is us. We are users and what we want are shiny new features. Obviously we want shiny new features as frequently as possible. And the best are now or even yesterday. And you might relate to this if you had a phone back in the 90s, some Nokia with or without the snake game and thinking about it, if you didn't have the snake game, what did you do to get it? You actually, you had to buy a new phone. You couldn't just install it. And there was like this thing, data cable. Some of you might remember the data cables that you had to buy in the store and what you could do is that nothing. You could probably back up your contacts to move them to a new phone when you buy a new phone to have a snake game. But obviously everything changed with the iPhone 2007 and all the smartphone revolution. And now if you want a snake, you just go to Google Play Store or Apple Store or App Store and just download it. And you know what? Day after day, you have new features. You have new levels. You have new features of or your app and beat installed. And this is something that we demand from the market. We as users and then we provide it to the users as developers. This is something that we are all very used to those days and probably those companies who don't do that will become Nokia for that example of our phones, if you wish. The other reason which is also very, very important is security. And as every company becomes a software company, security vulnerabilities become the new oil spills. They become the most threaded thing now. And you can remember a couple of them that were really big deal, probably as big deal as oil spills back in the day when we had oil as the king of the economy. The way to think about fighting security vulnerabilities is a little bit as the way to think about stopping distances back when you got your driving license, if you remember. So there are two different components to stopping distance. What they call a sinking distance and what they call a breaking distance. And they are completely different in what they are. So thinking difference is the neurons that fire in our brain as a reaction to light getting to our eyes retina. And then the electricity that runs through our body to the muscles that actually push the brake pedal. And that's one kind of this formula. And the other is completely different. Breaking distance is about the brakes that hit the wheel, that hit the wheels and the chemistry between the rubber and the pavement. That's like completely different thing. Now, what's common between them is in order to shorter the stopping distance, you actually have to invest in shorting both of those with completely different tools. So with breaking distance, you come with new alloys for the brakes, you come with better pavements, you come with better tires. And for thinking distance, basically the only thing you can do is replacing drivers who are slow humans with machines, the autopilot, which react much faster. But anyway, two completely different aspects compose one battle. And it's the same with security vulnerabilities. You can think about three different aspects of fighting those vulnerabilities. You have to identify that you are under attack and then you have to fix the problem, patch it. Most of the times that will be just upgrading your dependencies. Dependencies might be an operating system patch that will close this vulnerability and entire new operating system and all the way to replacing the dependency in your code in order to patch the vulnerability. This is what we will do most of the time. And then the third aspect of it is the deployment. And this is where continuous pipelines, continuous updates become a big deal because this is where the fastest you will update, your application, the better you will be. Sorry about that. I hope that's not the coronavirus. It's good that it's a remote webinar. So even if it is, you're safe. And well, the fastest you will update your software, the better you are. And a couple of examples in this regard. So you might remember almost three years ago now, the vulnerability that took down the NSA hospitals and stuff like X-ray machines and MRI machines were completely shut down because of the virus, PETA, not PETA, whatever run somewhere, hit them. So identify those run somewhere is designed to be identified immediately. But the fix, the fix is actually upgrading of the operating system. The problem was that those hospitals run Windows XP which was out of, after end of life, by then no security patches. This is why the vulnerability that this ransomware used wasn't patched. And obviously it took years for those hospitals and the system to upgrade their operating system. And this is why they got hit. Another example that you might remember is the Equifax debacle. And what happened there is that attackers used Strats 2 vulnerability that was out there before they even identified for two months. And the update was just changing the Strats 2 version in their POM file. And then it took them another two months to actually deploy it to production to upgrade their production services. And while we cannot know if shortening the vulnerability period from fourth months to two months was actually doing any favors, but we can expect that they have been in better shape if the upgrade was faster. So basically we're talking about more like an enterprise companies or government agencies that are very slow on upgrades. And you can say, well, in our environment, this is not the case. We know how to update our software immediately as so that won't happen. And that's all good news, but it's not enough. We started the last year a year ago with the announcement of Spectre and Meltdown attacks that you might remember. And while people spoke mostly about Meltdown because 10 lines of JavaScript code could expose passwords from different parts of memory, I would claim that Spectre is much more dangerous. The problem with Spectre is that, as opposite to what this article say that they, well, here, so what they say is most malware explodes coding errors and poor design. Now Spectre, the problem with Spectre is that it's the other way around. It actually exploits good design. The Spectre class attacks work by observing how a well-designed applications affect the speculative execution in memory and what decisions the CPU makes based on certain conditions in the code. And then they assume that a lot of other software is written in the same way will lead to the same speculative decisions. So the better code you write, actually the more it is vulnerable for Spectre class attacks. And that basically means that they are impossible to defeat. What are you gonna do? You're gonna write bad code just to confuse the speculative execution? Obviously not. So the problem is really that we start with zero-day vulnerability. We start with, okay, this code is vulnerable and now it's a race against the attacker. And the race against the attacker is we need to identify the problem as fast as possible. We need to fix the problem as fast as possible and then we need to update as fast as possible. And updating as fast as possible, that's what this talk is about. Now on the bright side is that we are in a surprisingly good shape when it comes to continuous updates. Instead of DevOps report that many of you are familiar and whoever not definitely should go and read that's the most important document in our industry. And that's a report that is built by what used to be called DevOps Research and Assessment Institute, which is now part of Google Cloud with Dr. Nicole Forsgren and Jess Humble and Jin Kin and other wonderful people who survey a lot of organizations, more than 35,000 for last year. And they build, they ask them questions and measure them on four different measurement scales. And that's the lead time, how long it takes from a code to production, the frequency of deployments, how frequently deployments are done in this organization. And then the rollbacks, the failures of the deployment, what percentage of the deployment fail and then time to recovery, how long it takes to recover from a service if a service goes down. And they take those questions and they group the organizations by cohorts. And you can see that we have 20% of the industry are in the cohort of elite performance. And that's every fifth organization doing a very good job. And those are obviously great news. And you can see that those elite organizations actually deploy multiple deploys a day. That makes them obviously able to provide the value of those features to the users faster and also to be protected from vulnerabilities because they can, or as much protected as they can be because they can update immediately after the problem was identified and the fix was available. And obviously they make them easier to recover from failures and all the rest. But for the sake of our discussion, those are the two main components. The fact that they can be rolling out features as fast as possible and that they can protect from security vulnerabilities. So 20% of the industry already does that. And that's because it's not a new idea by any means. Extreme programming 1998 actually advocated for a short feedback. And that means releasing faster and then scrum reducing cycle time to absolute minimum, releasing faster. And then Toyota production system decided as late as possible and deliver as fast as possible, release faster. And Kanban incremental change, smaller batches release faster. All those are not new ideas. And this is why 20% of the industry already successfully do that. So as I was introduced by Jeffrey, my name is Baruch Sadogurski and I'm the chief sticker officer in JFrog. If you need stickers, hit me on Twitter. I will hook you up at Jay Baruch. That's my Twitter handle and by now you should totally follow me. I promise you free stickers. And if you're still not sure about the stickers, my Twitter handle is on the bottom of each and every slide. This is the most important slide of this presentation. I've prepared a special page for you. Jeffrey comes to show notes, you go there and you find a page dedicated for this webinar. The slides are already there. The video we will upload later today. All the links to everything that I mentioned including the state of the ops report and everything else is there as well. The place to comment, to rate this talk and a small token of appreciation for you joining this webinar, a raffle, amazonicodot go there and participate in this raffle as well. As I mentioned, the bottom of every slide, you have the link to show notes as well. And my Twitter handle, the Twitter handle of Cloud90 Foundation that organizes this webinar and the liquid software hashtag that I will talk about a little bit later. So with all this introduction aside, let's cut to the chase. So we want to update faster. I hope I convinced you that updating faster is a good idea. So let's see what can go wrong. And the first example in question will be Java. A micranel who is, Marco, who is the platform, I think ahead of platform for Java. The most important guy in the Java world announced more than two years ago now that Java is moving forward faster. Java will release updates faster. That was, as I mentioned, three and a half years ago. And that was when Java 8 was in the release and the announced what we are going to release every six months instead of every year and a half, two years, three years, four years. It was really not that frequent. Every six months, no matter what, you have a new Java version. Since then Java 9 was out, Java 10, Java 11, Java 12, and Java 13. Five Java versions was released since the announcement. And let's see how that worked. So we look at the state of the developer ecosystem report from JetBrains. That's the last one. By the way, they're now collecting answers for a new one. So go ahead and participate. But that's the last piece of data that we have. And by this report, we can see that 83% are still on Java 8. Just to remind you, Java 8 was out when the announcement actually came out. And you go like, doesn't make any sense. We just made a case for faster updates and Java made updates more available why people are not updating. To understand what happens, we need to understand how we actually update. For that, I prepared a small diagram for you. This is how we think about it. So update is available and then we need to decide do we want it. If we decide that we don't want it, there is nothing interested like Java 9, then we say, okay, no, I don't want to update. But if there are interesting things like every new Java version, then you go like, okay, are there high risks? If there are no high risks, you can just update. And you can think about tons of examples for that starting from the non-mission critical apps on your phone. You have a new version of a game. Do you update it? Yes. Or Netflix, new version, would you update? Yes. And there are no high risks because if something go wrong, well, you're going to watch Hulu for a day, no big deal. Now with Java version, that's your production systems and there are obviously high risks. And the next question is do you trust the update? And to answer this question, I tried to come up with a vendor that updates you blindly trust. And the closest that I can think about is Apple circa 2000, let's say, 14. If you've been on the Mac back then and you saw a new update for Mac OS, you probably, and this is, you definitely want it, there are nice features. It's super high risks that you're working machine or your life in this laptop, but you trust Apple, so you go ahead and you update, no questions asked. So this was nice. Since then, well, not so much. And if I will ask you how many of you who are on Mac updated to the latest Mac OS operating system, Catalina, that was out for like three months, I guess the percentage will be around 10%. And that's because you want the features maybe either sidecar, there are nice features and there are very high risks, you don't trust the update. So the question is now, why don't we trust our vendors anymore? What happened to the trust that we used to put in them? One assumption will be, well, they forgot how to do a QA. Apple in 2014 knew how to do QA by 2020, they forgot. Well, I don't buy it. We only get better in the things that we do. So that's kind of a very weird assumption to make. I would say that the other hypothesis is the complexity. And obviously the complexity is going up and we and Jeff Rog as the authors of some tools for managing binary files, measure everything in binary files and artifacts and we measure complexity in artifacts as well. So you can see how the numbers of artifacts that we need to manage grew over the years starting from Agile back in 2000 when we started to do continuous integration and that means building more and more and then continuous delivery. That means that every artifact now might end up in production. So we need to keep them around and manage them infrastructure as code or suddenly or our servers and hardware or software as well. And then microservices raise the complexity dramatically. Obviously Docker, every line we change in the Docker file now produces a set of binaries that we need to manage and then serverless every 10 lines of JavaScript code is now an artifact that need to be measured, that need to be managed and versions and controlled. And then obviously IoT now those 10 lines of JavaScript code leave in every light bubble in my house. So that makes it even more hard to manage. So complexity plays a very big role but I would claim that another problem is even more critical and that's a problem of having a lot of data. So this is kind of a prediction of global data sphere by 2025. Zetabytes is a lot. Today we think about petabytes as a lot and when we speak about big data, we refer to petabytes. There is one more after and that's exabyte and that's like really a lot. And after exabytes, this is Zetabytes. Now this is something that we cannot even grasp as of today. And although this source of this research is a Seagate which might have interest in inflating the numbers a little bit, but even if we divide it by 10 and we say it's 17 Zetabytes, it's still, it's not comprehensible. And that means that officially staging is dead. And what I mean by that is that there is no sense economic sense in trying to replicate production environment that will look for staging and build environment that look like production just because the amount of data is so big that it doesn't make any economic sense. And the big companies already testing in production. And one of the interesting examples that I experienced personally in testing in production a couple of years ago, can go on Facebook if you have an account and search for this hashtag and empty envelope from China. You can find a set of blog posts by my wife about a very strange thing that happened to her. She had an account in Aliexpress to buy some stuff and suddenly out of the blue she had, she started to receive empty envelopes from China from different providers or look like this Aliexpress thing but she didn't order anything, there are no charges. Everything was clean on her side but envelopes kept coming.  And we were really puzzled on what's going on. We started to develop all kind of interesting conspiracy theories. And then my good friend Leonid Golnik who is the senior vice president of engineering now in SignalFX came to visit and we told him this story and he's like, I don't even know why are you surprised? Obviously testing in production. They took a subset of production database and run their provisioning test on it to see that everything works and the goods get out and this kind of stuff. And well, that made sense. And this is one of the examples of how people don't use staging anymore because staging is dead. So now we can know that data and complexity are a really big problems in guaranteeing quality and the question is, okay, so we don't trust those vendors, what do we do about it? The next question is, can we verify the update? Sometimes we just say, no, it doesn't make sense. New Java version every six months it will take me eight months to do acceptance testing on all my production environments and check that everything is correct. It doesn't make sense to update now to the next Java version by the time I will be done with my acceptance testing, new version will be out. So no, I just want to update. Or if I really, really want to, then I need to do all the acceptance tests. I need to do the time consuming verification which makes the dilemma for us as software providers because now in order to convince our users who will do acceptance testing because they don't trust us because the complexity and the data, we need to put a lot of food on the table. We need to make sure that we have so appealing features that people will update regardless of the acceptance cost. So we have a trade of now features that we really want acceptance test costs and we as users need to decide whether we should update because the features are so great we are willing to live through the acceptance test costs or we want to update to this version at all because the features are not so great and the acceptance costs are very, very painful. Can we go around this trade off in some way? Can we cheat in some way? Well, we can. In this case, it will look like update available. Do we want it? Yes, or yes, because now what will last us? Auto update is turned on and now we will get the update regardless of what's going on. And this will only work for stuff that is not high risk. And examples of that is your browser. I bet the majority of you have no idea what version of browser are they running or Twitter in your browser, that's a website. There are some versions behind the scenes but you have no, even a way to know which version is that. Twitter on your smartphone, there is a version, there is an update, but for the majority of us now auto update in turn off, it updates automatically, you have no idea what version it is. And what all those have in common is the low risk. Now for example, the operating system of your smartphone. Here you probably know the version because updating the operating system is something that requires human intervention because the risks are high. And this is where you go into this dilemma, back to this dilemma, are there enough features and do I want to take the risk of updating for those features? So now let's talk about building distrust because this is what it's all about. If we can build the trust to the level that the consumers trust that again, then there is no problem with making them updating faster and joining the features and being productive against the vulnerabilities. So what can possibly go wrong? And in the spirit of the personal stories that I started with, here's another one. Some years ago, I bought Google Wi-Fi which was called OnHub back then and that was a router from Google. Amazing piece of technology, still loving it. One of the features that was really appealing is the self-improving system. Self-improving system as known today is the over there updates. It's sitting there getting updates once in a while and actually getting better and better with time. And one day, three years ago, I was on a trip and my wife is calling me and she's like, I came back from work and our kids are sitting in the dark. And I'm like, is it the power outage? And she's like, no, the electricity is fine. The internet is down. And the kids are shouting, Alexa turned the lights on, Alexa turned the lights on, nothing happened. So they just sit in the dark. So that day they learned that there are physical switches on the wall but the internet was still down. So I called our provider, our provider like everything is good. But then I get this email and this email goes like, oops, sorry, we send an over there update to your router and it reset it to their original settings. So now we cannot fix it with additional over there update because your system is disconnected from the internet so we cannot reach it. And now you need to go ahead and reconfigure it from scratch. Now the problem is to get an email, you need wifi, you need internet. I was on a trip. So I was on a conference wifi or hotel. So I got this email, we configured it and everything worked fine. But yeah, there was this problem that update can go catastrophically wrong and over their patch cannot reach the device. And in our example, it was mild, it was just a reconfiguration of our router at home. But think about controllers edge systems on a solar array somewhere in Sahara Desert. It will take like three days to even get there in order to reconfigure it. And three days are, it's a lot of production lost. The solution to it is having previous versions saved on the device to update and rolling back if the problem occurs. The beautiful thing about this is that it's not a new idea. And this is a screenshot from, I don't know, Windows 98 that did exactly that. You remember when you had your desktop computer connected to a display and you changed the resolution. There was this warning on the screen when you come back should we revert the settings. And this is because if the resolution didn't match to the display, the display go dark and then you have no way to roll it back. So instead, there was an automatic rollback building in case something went wrong. And this is exactly how it works with all cool rollbacks today. Well, they are a little bit more complicated but that's exactly the same idea. And unfortunately, Google Wi-Fi back then didn't have this feature. Well, I mentioned again, low risks because that's a router at home but I would expect other devices to have it if they are harder to physically reach and fix. Now this is obviously an IoT example about the router and the edge device that I mentioned are from the IoT domain but I would argue that the T in IoT stands for things and things is everything including the servers that we update in our data center the servers that we update in the cloud and basically everything else. And if you are talking about fun stuff to update in IoT domain let's talk about updating cars. Again, what can possibly go wrong when you update cars? Here's a wonderful example Jaguar I-Pace released last year very luxurious obviously electric car that had a software bug in their brakes. Well, when that happens, what do you do? If you don't have software updates then you just have to do a recall. This is what Jaguar did. And the problem with the recall is that they are very costly. You have to have a network of services that will do the recall and will implement the fixes and you pay a lot of money for those recalls. And the other problem and one can argue it's a bigger one you can not actually force an update. What are you gonna do? You're gonna send them a mail like a letter and maybe in a red envelope to get their attention but in the end of the day if they are not willing to do the update to answer the recall, they just won't do it. And obviously when you have a problem with brakes that's kind of a big deal. And obviously the way to solve it is using over the air software updates preferably continuous updates. And the difference between the normal over there updates and continuous updates is this for example. So that's another software driven car and that's Tesla and one of the problems with Tesla autopilot namely is what it's called a Phantom Braking. Phantom Braking is you drive the car and the conditions are perfect. There is no interference out of the blue the car slumps and breaks. And there was a rumor that there is a fix coming out and people are waiting for this fix weeks after weeks. And the reason they didn't get this fix is because chess. You can see here an update which include this bug fixes small minor bug fixes note on the release notes and that's is the fix for the Phantom Braking. But the people didn't get it because they waited for this big feature which is a chess game to come out. And there is chess game in the Tesla that you play while your car is charging, it's fine, it's important. Is it as important as fixing the Phantom Braking? Well, depends to whom. If you use the autopilot features obviously it is more important for you. But if you are a chess enthusiast and you don't use autopilot is the other way around. Chess is the most important features. So regardless of what waited to what when you do batch updates, important features whatever is important for the user and that might differ between the users wait for non-important features, right? So for me, I had to wait for chess to get the fix for the break. Someone else had to maybe wait for this irrelevant fix for their autopilot while they're waiting for the chess features. So instead, you implement continuous updates you implement over the error updates and then you deliver the features as they come out. And now I want to make like a very short quiz Paul to make sure that you are not asleep at least. And I want to ask you how many of you are IoT or mobile or mobile developers? So let's see if we can, here we go. Are you an IoT or mobile developer? Let's see the results real quick. I don't think I have an access to the results. So yeah, Taylor, can you tell us what the results look like? So far out of the 63 people that voted 57 are not and seven are. Okay, so you see the minority of you. Seven people are the IoT or mobile developer, the rest of you are not. And that's obviously a cloud native webinar which is about cloud and server side. And you might think why are, even I waste your time talking about that. But the thing is our life as servers are developers as cloud native developers is easy comparing to the mobile and the IoT world because for IoT mobile and automotive, they don't control the availability of the target they're updating. They don't know if the computers are on or off. They don't control the state of the target. They don't know if there are implied requests. If there is something happening on the device, they don't know which version are they going to update. Maybe this device didn't get updates for last three years and the other device is in the latest version. And they don't have access to the target in case something went wrong and they need to log into it. You can always go and log into our servers and see what's going on. They don't have this luxury.  And the biggest example, it's a little bit old. It's like eight years ago, but it's so powerful that I feel that I want to share with you is the night capital disaster. So night capital was a trading firm doing automatic trading on New York Stock Exchange and they decided to roll out a new system. For some reason they decided to reuse some old APIs. And now the same APIs did something completely different, selling instead of buying, think about that way. And for some reason during the update, one of the eight servers was not updated. And new clients now send requests to seven new updated machines that did what needs to be done, but one machine contained the old code. So it did something completely different and the engineer so that it misbehaved and did something different. And what they do is, okay, we need to stop the upgrade. So they shut down the updated machine and now 100% of the traffic goes to the machine that did something completely wrong. And there is no monitoring, no alerting, no debugging and basically think about it. They are sitting and trying to debug what's going on in real time and they are actually losing millions of dollars every second they did it. The fix took 42 minutes. They lost more than $400 million during those 42 minutes and basically went out of business. And that's a horrifying story. I have a link to more detailed explanation of what happened in the show notes, just to remind you, jefford.com says show notes and there is like, it's a marvelous story and a really, really scary one. What could help? First of all, people are just bad in repetitive tasks. So instead of manually updating servers, we automate everything and this is how we make sure that eight servers out of eight are updated. And then another problem is that they did this deployment after many years of not doing any deployment to production and obviously they had no skill, they have no habit of doing that. And that was a very stressful event, things went wrong. Instead, if you update frequently, you develop skill and habit and it's not a big deal. So the chances of you screwing up are lowered. And another problem is they reuse some state on the target machine. That might be a good decision, might be a bad decision, but regardless of that, you really need to know and consider the target state when updating and reverting my require, sorry, and reverting my require revert of the state and knowing what will happen during reverting of the updates. So another marvelous example, and this is pretty fresh, that's July last year, is Cloudflare. Cloudflare went down to most of the internet with it. What happened? So Cloudflare battles, DDoS attacks and other type of attacks on the internet with routing rules that they deploy frequently and they deploy it all the time. And one time in deployment of a single misconfigured rule.   That's a quote from their status page. Some humor, definitely a needed situation. So yeah, affected region earth, everything is down because of single misconfigured regular expression. And this is weird because you expect from a very progressive company like Cloudflare to actually implement a progressive delivery because what they did is they released the bug that affected all users. Instead, you should release to a small number of users first, effectively reducing the blast of radios and then observe. And if a problem occurs, you stop the release, you revert or updated the affected users. And the most important, the most interesting part of it is that progressive delivery, it's something that the majority of us probably learned when we were like eight years old when our parents teached us how to do laundry because every detergent have this warning, always spot test on a hidden service first. And this is progressive delivery. You try somewhere to minimize the blast, to minimize the damage, and then you observe and check if it works or not. And if it doesn't work, you don't do it or you revert it or you do something else. So this comes obviously with observability. Some feedbacks are hard to trace relying on user feedback only. People yelling on Twitter is a good feedback, probably not good enough to troubleshoot the problem to the root. Instead, tracing, monitoring and logging help with that as well. Rollbacks, so now you tried it and you see there is a problem.  So fix might take time, users suffer on the meanwhile. Instead, you implement rollback, the ability to deploy the previous version without delay. Now it sounds reasonable and simple, not every platform supports it. So for example, when you are on mobile, not Google Play and not App Store allow to do rollback. If you have a problem and you wanna rollback to a previous version of the same app, you actually take the previous version, rename it as a next version and then submit it to review. And the review will take whatever it will take, three days, five days. You can flag it in urgent. If you're still not in luck and it's Friday, you won't get it until Monday. I mean, there is no way to rollback version in the mobile world today, which is a very sad state of first. So instead you can use feature flags to implement kind of rollback. You embed two version of the app and you control them with API calls and then you can turn off the misbehaving part of the app for those who are suffering. And I think the last one as the most dramatic example is MoviePass who they shut down their mobile app for several weeks to update. And that's just ridiculous because we're talking about zero downtime updates and someone go ahead and promise to come back with an app in five weeks. Probably by the time they come back, they won't have any users. That's exactly what happened to MoviePass. They went out of business after updating their app for five weeks. And then obviously the opposite of it, zero downtime over the updates of small and frequent continuous updates is the way to go. So just to summarize, continuous updates are frequent, are automatic, are well-tested, progressively delivered, state-aware, observable and implement local rollbacks. Those are all obvious stuff. Local rollbacks can be challenging. That's kind of an extra credit task, but still necessary sometimes to implement. And now what we have is we have an update. Do we want it? Doesn't matter. Automatic continuous update. And then there are sometimes no high risks or even there are high risks. We are now trust the update and then we update without fear. This is what we want to end up with. And for that is our goal to transition from Balkan Rare software updates to extremely tiny and extremely frequent software updates so tiny and so frequent that they provide an illusion of software flowing from development to an update target. And we call it the liquid software vision. This is why you have the liquid software hashtag on the bottom of every slide. And this vision is encapsulated in the book. It's called liquid software and have the concept of a continuous updates and two co-founders of JFrog, Fred Simon and you have Lyman and yours truly co-authored this book. And the good news are is that if you ping me on Twitter in DMs or even publicly, I will be more than happy to send you this book to ship you a physical hard copy of this book. Ping me on Twitter at Jay Baruch and you will get this book after this very long. Before we wrap up, I want to talk about corner cases and we believe that the majority of the software should be delivered in a liquid software way with continuous updates. Are there any corner cases? And to give you an example of such a corner case, I would like to ask you another question and that do you think that updating an aircraft mid-flight is a good idea? So you will have the poll up in a sec and you will be able to express your opinion on that. Oh, here we go. Do you think upgrading an aircraft mid-flight is a good idea? Let's see what we have. And again, Taylor, can you share with us what people say? Absolutely, right now we have 84% say no and 16% say yes. Okay, 16% say yes, that's a lot. But let's see if we can drive it even harder. So here is Airbus A350. Airbus A350 has a memory leak and it needs to be rebooted every 149 hours. If you don't reboot it, memory leak software crashes, software that actually flies the plane. So here is a hypothetical situation. You are now on a flight from San Francisco to Tokyo over the Pacific or the past Hawaii. You have like three hours, I don't know, five hours more to fly and then the co-pilot asked the pilot, hey, by the way, did we reboot this morning? Because I think we kind of run out of this 149 hours and they're like, oh no, I think we forgot. Do you think that patching this memory leak mid-flight, sending continuous update that actually fixes it would be a nice idea. You might start thinking differently than you voted and to prove that I'm not the only one and you are not the only one who thinks it might be a nice idea, here is a proof. And this is from the great book from Project to Product. You know where to find the link. Jeffery.com for show notes. Boeing 777 had a problem during the design of wheeze stabilizing the shaking during turbulence. And they couldn't debug it on the ground. So they took all the software engineers, put them on the flight, took off, went to the turbulence zone, debugged it in flight and found the problem and actually updated mid-flight to make sure that the fix helps. So this is something that is undone. This is something that definitely might be a very good idea. The secret is to trust the upgrade and to trust the update, there are very good advice in this webinar and also in the book. So wheeze that just to summarize, my name is Baruch at Jebaruch on Twitter. Liquid Software is the hashtag that you use on Twitter when you talk about that. At Cloud90 Foundation is the Twitter handle of the Cloud90 Foundation that hosts this webinar and liquidsoftware.com is a website of the book and you can learn more. And Jebaruch.com session is where you go for the slides, the video, all the links, comments and ratings and your chance to win Amazon Echo Dot if you fill out a little form. Wheeze that, thank you very much. I think we have like a couple of more questions, a couple of more minutes for questions. If you have any questions, type them into your Q&A panel in your Zoom. Yeah, we do have just a few more minutes, but if there are one or two questions, you should have time, all right? No, I think, yeah, there are no questions. Just to remind you, if you want the book ping on Twitter, I will be more than happy to ship one to you. Wheeze that, Taylor, Jeffrey, thank you very much for having me. Yeah, thanks Baruch for a great presentation. That's it, thank you for joining us today. The webinar and slides will be online later today and we look forward to seeing you at a future CNCF webinar. Have a great day everybody.


This video is for all of you who live in the US but have parents back home in India. I am going to talk about all the questions that they need to prepare for in the visa interview and also the documents that they need to carry with them. Keep on watching. Hi guys, my name is Shachi and I am a travel and visa coach. On this channel you will find tons of useful videos on the US visa process right from filling the form to clearing the interview. Make sure that you check them out. So let's get started with this video and let's see how you can prepare your parents for the B2 tourist visa. So let's start with the questions that can be asked in the visa interview and in this video I am going to cover 2 of the most important questions that can be asked to a parent for a B2 tourist visa. The first one is purpose of visit. Now this is the most important one and it is very very likely that the parent will be asked by the visa officer what is the purpose of your visit to the US. When asked this the parent needs to state very clearly that their son or daughter is living in the US or working in the US and they plan to visit them for a short period of time to spend time with them and also to do a little bit of tourism. Make sure that they know all the details of your job such as the company that you work for, your designation, the number of years of work, and also which visa you are on in the US and the details of those visa because these are generally the follow-up questions that is asked by the visa officer and it is important that the parent is well prepared for this and to round things off make sure that they have a copy of your visa and your passport with them when they go for the interview. The second important question that they need to be prepared for is reasons to come back. A lot of times visa officers have a concern that the parent might overstay you know their visit in the US or they might not come back at all and to elevate these concerns it is very important to show that the parent has a stable life and financial income back in India. Some of the reasons for them to come back could be their career if they're still working, other children who live in India, long-term investments particularly in real estate so if they own land or property then this should be definitely highlighted and also having a community life and family life in India. So these are the pointers which show that they have a stable life back home in India and they have enough reasons to come back. So they're not working and they've already retired they can also highlight the roles that they're playing in the community or in the society by talking about the work that they're doing say for an NGO or a charity and so on. So as part of this video we actually have a free PDF which lists all the possible ties that one can have to a home country. So this PDF will help them recognize what are the ties that they can talk about in the interview and prepare accordingly. So do check the link in the description box below to get your free PDF. Next let's talk about the documents that are required to be carried by them to the visa interview. Now the document list will vary for each person and it really depends upon the profile of that person. So if you want to get a customized document checklist for yourself and your parent then do get in touch with me over email or over Instagram DM. But in this video I'm going to talk about the most common and the standard documents which are really really important for the interview. The first one is a sponsorship letter. So if you are sponsoring your parent's trip which means that if you are going to pay for all their expenses such as the flight expense or they're going to be living with you and also the expense of staying in the US then you need to give them a sponsorship letter and the sponsorship letter has to be given to each parent so it has to be separate for each visa applicant. We actually have a full video explaining the concept of sponsorship letters, how to go about it and what are the documents that you need along with the sponsorship letter. So I'm going to leave the link for this video in the description box below. Make sure that you check it out. The second one is financial documents. Now many times a child is sponsoring the visa of a parent and that is completely fine. But at the same time it is also important to highlight the financial resources that a parent might have. This is something which we discussed earlier in the video and this helps to show ties to the home country and enough reasons to come back. So make sure that your parents prepare their financial documents and highlight their income sources back in India. It could be income from pension, it could be rental income or it could be income from other businesses or income from investments. Third comes the travel details. Now when they go for the visa interview, it is not mandatory to have the flight tickets booked or to have all the travel plans already laid out. But it is important to know some details and one of them is a travel itinerary. So a travel itinerary is basically a day by day plan of what they want to do in the US and this is something that they should prepare for. So basically a very simple way to prepare a travel itinerary is to make a table with two columns. The first one lists the date and the second lists the plan for that day. So try and prepare this itinerary for them for the duration of their stay in the US. Make sure that they carry this with them to the visa interview. Also they need to know details of the address where they'll be staying in the US. So if they're going to be staying with you then they need to have the copies and details of all these addresses with them. The fourth one is details of your visa and employment. So this is something which I already mentioned at the beginning of the video but it's really important so I'm going to stress on this again. They need to know details of the visa that you're on in the US. Have a copy of the visa with them and also details of your employment. So your job, your designation, where you're working, what you're doing. All of these things can be asked to them by the visa officer. So ensure that they're prepared for this. So I have worked with a lot of parents and I've helped them get their US visas to visit their children. So in this video I want to present to you a case study. Now this case study is a real life case study and it is in fact from one of my clients. And this will just help you to understand everything in a nutshell and put things in perspective. On the screen right now you can also see the review that was written by this client after they got their visa. So first let's start with a little bit of their background. So they were basically a married couple who were settled in India. They were retired. And they had one daughter who was living in the US and she was married. She had a child and in fact she had just moved to the US about a year ago, I think from Australia. So in their case, the first time that they went for the visa interview, the visa got rejected. And the reason for this is that instead of stating very clearly that the purpose of visit was to visit the daughter, they went about a slightly complicated way of saying that they wanted to go to the US for tourism and also to visit a couple of friends and so on. So in the course of the interview when the visa officer found out that they in fact had a daughter living in the US, he just found the entire setup slightly suspicious and hence rejected their visa. So we worked with them for their next visa interview. And the first thing that we did was to simplify their purpose of visit. So the purpose of visit was made really simple and it was focused and centered on visiting the daughter and the grandchild. The next thing that we worked with them was to strengthen their ties to the home country. And this was really important since they were retired. So they didn't have a career or a job to come back to. And they also had just one child who was already in the US. So we worked on highlighting their other sources of income, such as income from their rented property, from their investments. And also in highlighting the role that they were playing in the society. So they were a part of a couple of NGOs and a couple of charity. And they had some work going on there. So we worked on really highlighting this and bringing it into focus, which showed that they had enough reasons to come back to India. To make the long story short, when they went for the visa interview the next time, the answers that they gave were genuine, they were simple, they were to the point. And they also showed very, very clearly that they had a strong purpose to go to the US and enough reasons to come back to their home in India. And of course, they ended up getting the US visa and I'm happy to report that they were able to visit their daughter and spend time with her and the grandchild. So if you two would like my help in preparing your parents for the US visa interview, then do get in touch with me. You can book a one-to-one consultation session. This will be done on a video call and this will help them prepare their profile, prepare their answers, and make them more confident. So details of this is in the description box below. Make sure to check it out. I hope this video has helped you. If you have any more questions, feel free to leave them in the comments section below. You can also DM me on Instagram, my Instagram DM is at shachi.mul. I'll be happy to help you out. Do check out my website as well, shachimul.com because on this website, you'll find a lot of useful resources. There are a lot of free resources as well as paid ones such as a DS160 toolkit and interview toolkit, which will basically make the entire process of getting through this US visa interview really, really simple. So the detail of all of this is in the description box below. Please go through it and check it out. Thank you so much for watching. I'll see you in the next one. Signing off till then, bye.


Biotechnology is a broad area of biology involving living systems and organisms to develop or make products. For any technological application that uses biological systems, living organisms, or derivatives near rough, to make or modify products or processes for specific use on convention on biological diversity, art, too. Depending on the tools and applications, it often overlaps with the related fields of molecular biology, bioengineering, biomedical engineering, biomanufacturing, molecular engineering, etc. For thousands of years, humankind has used biotechnology in agriculture, food production, and medicine. The term is largely believed to have been coined in 1919 by Hungarian engineer Kareli Harevki. In the late 20th and early 21st centuries, biotechnology has expanded to include new and diverse sciences such as genomics, recombinant gene techniques, applied immunology, and development of pharmaceutical therapies and diagnostic tests. The wide concept of biotech or biotechnology encompasses a wide range of procedures for modifying living organisms according to human purposes, going back to domestication of animals, cultivation of the plants, and improvements to these through-breeding programs that employ artificial selection and hybridization. Human usage also includes genetic engineering as well as cell and tissue culture technologies. The American Chemical Society defines biotechnology as the application of biological organisms, systems, or processes by various industries to learning about the science of life and the improvement of the value of materials and organisms such as pharmaceuticals, crops, and livestock.3 per the European Federation of Biotechnology, Biotechnology is the integration of natural science and organisms, cells, parts and rough, and molecular analogues for products and services.For biotechnology is based on the basic biological sciences e.g. molecular biology, biochemistry, cell biology, embryology, genetics, microbiology and conversely provides methods to support and perform basic research in biology.


You're an agent. You're like, man, I want to do that.  I want to talk about a few things. Not only do I want to talk about Mediocrity I Want to also talk about mindset And I want to talk about goals and if in when you stick around to the end of this video I'm gonna give you a two-week challenge That you're gonna love. Okay, so first we'll talk about Mediocrity if you looked up if you look up what mediocre means Guess what? It means average It means average. No one Was put on this earth to be average. No one thinks that they naturally want to be average, right? But if you think about it, most people are mediocre in their in their life in Their workout Like that's that's more their health and also in their business. Most people don't ever go the extra mile They just kind of like float through because it's comfortable to just barely do enough Okay, so we think about mediocrity. Okay now. Let's move. Let's let's let's move to the Mindset piece. Okay, so for me For me, I want to have a healthy mindset something that's a mentally tough I'm strong. I can do anything I can get outside of my comfort zone on purpose, right? I can conquer fears I can do all the other things. Okay Most insurance agents this is the one thing they struggle with okay because you want to be successful It's right here, right, which is what moves me to goals Which is why I have goals because I want goals that are so big That it forces me for in my mindset to improve and to go up Okay, it's it's it's it's it's goes back to goals Right. So for for example, I Feel like even though I maybe I'm not from time to time I feel like in my life I get mediocre from time to time Especially when my in my workouts or you're you get complacent, right? You get in the same rut We do the same thing over and over and over again instead, I Wanted to get to where I was doing something big, right? So if I think about over the last decade in this business and things that helped me become a better insurance agent, right? I set a goal to make a hundred K goes back to goals my first year, right after that You know built a call center to where we're doing close to a hundred apps a month Okay, after that, you know, hey, yeah built a YouTube channel with over 20,000 subscribers built the a personation conference, right? To where it's it's it's becoming more of a household name in the industry, right? And we've had we've had we had 3,000 agents on our virtual event Back in April, right? So there's these and literally just got done running a half marathon Simply because I did I did I wanted to put myself outside of my comfort zone people thought it was nuts So I'm like dude, I got to challenge myself to do something like that Why because I don't want to be mediocre, but if but if we don't realize that in our business We are just floating through we're doing the minimum We're doing the average and we're just doing okay before you know it an entire year is gonna pass and you Didn't step out and do anything big You were okay your average you floated through and guess what it the year kind of you know the year kind of sucked because You did just enough to get by Once you get to where you want to do things that challenge you and you don't be mediocre And you push yourself past that point then you start to increase your mindset, right? Once you start to increase your mindset, you can do anything like you can force yourself like when I was running that half marathon I'm like when I was running it. I was thinking everybody's everyone told me For your first half marathon if you're not used to running long distance at all and I haven't run Previously before this month. I had not run a mile more than a mile in Like eight years, you know so everybody's like dude There's no way for you to run this thing and in under two hours sub two hours 13.1 miles dude It's impossible right so the whole time. I'm watching my time I'm average in nine minutes a mile. Okay, and I'm thinking like the first mile. I was like 855 Okay, the next mile. It was like a little bit. I think it was a little better Right then it was a little worse and then I got toward the middle. It was all over nine minutes It wasn't good man. I got to where I was up to 940 a mile at one point. I'm thinking gosh dang it I kept trending up to where my average was now at 905 a mile. I It was a moment where I can just be comfortable and get through the race and not beat my goal time Of two hours. I kicked it in high gear my last four miles that I ran were faster than my first one and Ended up Finish it in an hour 57 minutes, right? We're just barely in front of it. Why? Because I got out of my I got in my comfort zone didn't want to be mediocre I I let my mindset take over and force me to deliver and frickin do this and guess what? I ended up hitting one of my goals That's the big thing that most people don't realize is but you've got to put yourself outside of your comfort zone so that you can have and strengthen an Unbelievable mindset so that you can end up accomplishing whatever goals that you want in life Okay, now most people It's cool to be comfortable. It's cool. I you know, if you don't really want to conquer your fears You want to just be what you want to you know, I want to do that. I want to go to bed late I want to sleep in I want to play video games. I want you know what I mean I like I just I just I don't want to work that hard throughout the day I you know, I don't want to like stretch myself. I don't want to get in better shape, you know, I just I Just you know, I just want to make it okay, you know living and I just want to have an okay life And before you know it, it's like dude I'm operating in this place of mediocrity and and and I've had those moments in life where it freakin bothered me You know, like we have a lot going on now, but I feel like I'm getting complacent. I'm not pushing myself enough I don't have those new challenges to wake me the freak up and that's what people need That's people need to really like grow this thing, you know what I mean? And to really get outside of that comfort zone and to get to where you can have an unbelievable mindset because insurance agents Struggle with this piece Right the only reason why and the average insurance agent actually sits down with zero to three people per week is Because they don't put forth enough activity. Well, why would they not put forth enough enough activity? Because their mindset's freakin broke and they won't put in the work because they don't feel like doing it because it's It's outside of their comfort zone, right? It all comes back to this 92% of insurance agents fail if they but but but they only fail because of the stuff but right here Between the but but literally between the years. That's it If if if they will get to where they will do whatever it takes to actually sit down and ask 10 people to buy Every single week they wind up being successful and they won't struggle with this whole mindset piece But most of us struggle with a mindset piece Because we've never Been challenged. We've never put ourselves outside of our comfort zone We've never forced ourselves to operate outside of a place of fear and guess what then we end up becoming mediocre as an insurance agent Because we don't force ourselves propel ourselves push ourselves to do things that we do not want to do There's a lot of people in a in in our world right now They're saying dude only do stuff you want to do you don't have to do stuff You don't want to do right in this industry as insurance agent. It's the hardest career on planet freakin earth 92% of people fail it is the hard in their first few years by the way It's the hardest career in the world But there are more millionaires in this industry than any other industry on planet Earth It should be the most rewarding if it's most difficult, right?  Do you think I wanted to go knock on 175 doors on a Friday or a Saturday when I was 20 years old? Absolutely not sounds horrible Do you think I wanted to go in and cold call for four or five hours on a Sunday? While my friends are freaking taking a nap No But am I glad that I put in the work and did those things now and that I'm consistently trying to do stuff to put me Outside of my comfort zone and to challenge me. Yes. Okay, so here's the bonus I Just gave I'm coaching a client That's trying to grow is is is is call center phone cells I gave him a two-week challenge.  All right now. They got the mindset, right?  I'm gonna fix that right now There's a video how to increase your show ratio click on it. See you all right So you want to increase your show ratio who doesn't want to increase your show ratio because if you do guess what? You sit with more people and you end up making more cells, okay? So here's


So you know how to get a sprite pointing in the direction of nothing. Easy peasy, right? Do you know how to do it using trigonometry? If not, that's exactly what we're going to be doing in this tutorial We're going to be building an enemy turret so it can eventually fire some missiles at our rocket ship to make its life a little bit more difficult We'll be revisiting a tan in the process. What's more? So I'm going to share with you an advanced animation technique called blending and it's going to make our tracking motion of the Turret look super realistic. So let's get this moving in just a sec Hey, what's up crew? It's the surfing scratcher here teacher-surfer programmer And I help curious people just like you along on their learning journeys through video tutorials If you just jump into this tutorial check out the starter project down the bottom all the cards in the top right hand corner right now We've got our spaceship flying around the screen and we need to create an enemy for the enemy We're going to create a turret. We're going to paint a sprite It's like the circle tool hold down the shift key on your keyboard to draw a nice even circle Gonna zoom in a little bit grab the arrow selection tool drag it down to the center. There you go It's snap lock. We're going to change the X in the way of the turret to zero zero and you can see it's quite large So you might need to resize it press the old key to keep that nice Circular shape going get the size that you want might need to zoom in a little bit gonna copy it paste it on top Reduce the size put it back in the center. We're just going to change the color of it Let's make it a little bit darker cool Now grab the rectangle tool and draw a rectangle Now you don't want this to be in the center at the left edge of the cannon to be in the center And then trying to line the center vertically as well. Okay, that looks a little bit funky on the screen I'm going to sandwich the cannon between these two circles just by moving it backwards. There we go Looks a little bit long. So I'm just gonna resize it there great And there's our turret now just rename it to turret make sure that your turret is pointing in the west direction So then when we change the direction of it to zero degrees it is pointing north This is to align it with our rocket ships direction Just in the code blocks of the turret now when you initialize it click the green flag Set the x and y position and just get it to point in the direction of zero and grab out a forever loop When we move our spaceship around the screen, we want our turret to point in its direction And there's a really easy block to do that motion blocks point in direction of the rocket ship So now when we move the ship around the screen the turret is directly pointing it But that's the easy way and you're not here for the easy way You're here to learn about trigonometry and some advanced animation effects. So let's go explore that I'd like you to make a new block and call it rotate turret instead of point towards You want to rotate turret and we can get rid of that point towards now We're going to be using a couple of variables to help us out with this So create a variable call it target angle grab out a set variable block and change it to target angle Now i'm just back over here in the rocket ship sprite And we can use the same a 10 function that we used in the previous tutorial for our turret So i'm just going to grab our logic here and place it directly on the turret Now i'm back inside the turret sprite and there is our block of code for an explanation of how this works Check out the card in the top right hand corner right now However, we need to modify it. So instead of the x and y velocity We need the x and y position of the rocket ship The reason is because you're going to be drawing a triangle from the turret to the position of the ship So this point is the x and y of the ship in the sensing category drop down the reporter block with two drop down menus We're looking at the rocket ship. We want the x position of the rocket ship We also want the y position of the rocket ship where it says x velocity put in the x position Where it says y velocity put in the y position and that's what the block looks like Now insert that whole code block into the variable now We want to point in the direction of that target angle now when we move our ship around the screen Our turret is mimicking that point in direction block. Boom. Currently our turret is like fixed to our rocket ship That's not what would happen in real life. It would be lagging a little bit behind it So if you're looking for a challenge, i'll show you how to do that first things first I'm going to clear off all these variables on the screen and leave the one that has target angle. There we go Currently we're pointing in the direction immediately of the target angle We want something like a lagging angle. So go ahead and create a variable called lagging angle And we're going to be setting the lagging angle We're going to jump across the sketchbook now to give you some visual intuition of how this works Over here in sketchbook. We've got our x axis going across. We've got our y axis going up and down We've also got our turret and our spaceship We've also got a little test angle that we've got here and this green line That's referring to our variable of our target angle. We're just going to make our target angle 100 degrees That's represented here by our little yellow circle segment You can see our turret is currently pointing north and that is at zero degrees and this pinkish line It refers to our lagging angle and our lagging angle is currently zero degrees And we want our lagging angle to do something that you're seeing on the screen right now So starting off with quite big movements and then those angle movements reducing in size until we land at 100 degrees To help us do this We're going to be leveraging the power of percentages to help us visualize this I've just got a percentage bar starting at zero degrees going all the way up to 100 We're just going to piggyback the values on the x axis to help us out All right, our turret is at zero degrees and let's think about this little segment here first We know that it's a slice of a full 100 degree rotation So why don't we just make an arbitrary number and say this is a 10 Slice of the current target angle to get the 10 percent of the target angle in scratch We just to get that target angle and multiply it by one tenth and that's going to come out to 10 Here on our percentage bar 10 is just equal to here So saying when x is equal to 10 that just means 10 degrees So I'm going to color in that segment to represent 10 percent of our target angle Now we could repeat this for 10 times until our lagging angle is equal to 100 degrees So we'd have 10 slices of animation But notice how they're all the same width and here the widths get smaller and smaller So this is just part of our solution to set the lagging angle This 10 percent is going to be the same every single time But look we've got this whole 90 percent to play with now We know if this little segment here is 10 degrees Well, the rest of this is going to be 90 degrees because 10 plus 90 is equal to 100 So now we know that 10 percent of the target angle is just equal to this segment right here 10 degrees So we're just to race this out now. We know that 10 percent plus 90 percent is equal to 100 percent So we're going to leverage that we're going to take out 10 percent We're going to add it To something that's going to be 90 percent which is just nine tenths And the thing that we're going to take 90 percent of is the current value of the lagging angle So we can just take 90 percent of the current value of lagging angle and the scratch That's going to look like this This is probably not making a whole lot of sense yet But let's step through each of these segments and see what the values would be Let's start when lagging value is equal to zero degrees down here lagging value, which is zero degrees times 0.9 Well, that's just going to equal zero and zero plus 10 percent of the target angle We know to start with it's just going to be 10 percent That's always going to be 10 percent for a hundred degree angle So this first segment refers to lagging values first value of 10 Okay, so let's work out this second segment now So the current value of lagging value Well, that's now 10, isn't it because this is what the current value is We want to take 90 percent of it So we just multiply it by 0.9 and that's going to come out to 9 and just to show you that on the character there 10 times 0.9 Is equal to 9 and we know that this business down here is always going to be equal to 10 So this is just 10 plus 9 So our second value is going to be 19 and see how we've only added 9 We haven't added 10 to show that on our percentage bar down here I'm just going to draw a line that is just a little bit before 20 and I've just colored that in We know that's 9 degrees because 10 plus 9 is 19 Okay, let's do one more and we're going to look at this segment here Remember this line is referring to this whole rotation now So the current value is 19 So we want 19 times 0.9 going to need the calculator for that one It's equal to 17.1 and again we take our 10 and we add it to 17.1 You can certainly do that one now we're at 27.1 degrees Notice that each time we're adding a little bit less 27 on our percentage bar is somewhere around here And now I'm just going to color that in and this segment is equal to 8.1 degrees And when we add them all together, we're at 27.1 degrees Now this will just continue until lagging angle becomes the same as the target angle What will those values be? Well, what's 100 times 0.9 or 90 percent of 100? Well, that's just 90 and 10 plus 90 is equal to 100 degrees And so down here, this is our final block that we'll use in scratch So let's head there now Let's first create our percentages target angle get 10 percent of that Then let's get 90 percent of lagging angle We're going to add those two together We're going to stick that inside lagging angle And instead of pointing in the direction of target angle, we want the lagging angle So you can see now when we move our ship around the screen Our turret follows it and it's just slightly behind it If you wanted it to be even slower Then you would say lower 10 percent to 5 percent of the target angle And then you'd increase lagging angle to 95 percent You have to make sure that these values, the 0.1 and the 9 always add to 1 So everything's all well in our game until our ship moves from north to south and south north Over on the left side of the screen, something funky really happens with our turret As I move the rocket from south to north, check out the values of these variables You can see that it went from a quite a high number to now a negative number So what's going on here is that as our spaceship goes from north to south It's crossing over a border It's going from negative 90 to 270 And when it does that, it wants to make a full clockwise rotation of 360 degrees Which would happen to our turret There we go, our turret has just fully rotated The opposite is true when we go from south to north We're going from quite a high value of 270 to negative 90 when we cross the border So we're taking away 360 degrees Which would happen to the turret There we go The way to solve this is to force the value of lagging angle when we make that cross To help us out we're going to need a new variable Call it last angle We're going to set last angle to the target angle directly after we set target angle So what this will do while we're calculating the next target angle We'll know the last angle that it was So we're creating a boundary between the two known angles And we can do something like this If our last angle is greater than a number really close to 270 And our target angle is less than a number that's really close to negative 90 But not smaller than it Then we know we've just gone from south to north And when we do that we want to take away a full 360 degree rotation from lagging angle So let's change lagging angle by negative 360 And before we do the other one let's just test it out So we're going to take this if block and insert it between where we set the target angle and last angle Now I'm just going to get our ship headed south again And our turret did its funky little animation And when we go north it crosses the boundary beautifully I just duplicated that if block and we need to change it a little bit First thing we can do the nice easy one is just take away the negative symbol Because we're going to be adding 360 degrees And we just want to switch these two variables around Change last angle to target angle And where it says target angle change it to last angle So target angle is now greater than 267 And last angle is less than negative 87 And just for cleanliness we could switch these out So when we're north and we're going south change our lagging angle by 360 Slip that directly under that previous statement I'll get rid of these comments and let's test it out Our rocket ship now moves through that boundary And our turret is animating beautifully All right you made it well done congratulations And good on you for persevering with these tutorials They're not easy but you're sticking with it and I know you can do it So currently our rocket ship can just kind of drive straight through our turret And that's probably not what we want So we're going to create a health bar and some damage when we collide with our turret And we're going to be doing a little bit of collision detection as well And investigating the sign and cause trig functions So I'll catch you in that tutorial Congrats on making it through this tutorial And I hope it bolstered your understanding of percentages along the way We're edging episodes close to the halfway point of this series But we've still got a whole heap more to get through Find some value then be sure to smash that like button And hey I'd love to see how you're getting on with this project So drop me a comment down in the section below And if you're feeling up for it also share a link to your project I'd love to see how you're tweaking it to your style But until next time I'm off to go find a wave I'll catch you in the next one


Hey, welcome back to my channel, guys. Today I am going to show you how to make sloppy joes. Why is it called sloppy joes, you might ask, because it's really messy. But it's very easy, it's very economical, and it's a good filler meal, so great for those teenagers. Now in the States, what you do is you make your mince, and then a lot of times people just buy a manwich, and they just dump it in, because they can't possibly make anything from scratch in the US. But it's very similar to the mince that you guys make here with the mincemeat and tomato sauce and putting in various meals. But today I'm going to show you how to, a little bit of a different spin on it, a little bit different ingredients. So check it out, sloppy joes.


This is Nicole Rogalski with CalTV Entertainment and welcome to our first segment with our partnership with BAMFA this semester. Let's check it out. The UC Berkeley Art Museum and Pacific Archive, BAMFA, is located just off of campus in downtown Berkeley. It features over 20 gallery exhibitions and offers over 450 film screenings every year to the public. There are currently six exhibitions on display right now, ranging from a Nigel Poor feature made in collaboration with inmates in the San Quentin Prison to Japanese Zen-inspired calligraphy titled Meditation in Motion. BAMFA also offers an art lab that is free to all museum attendees to utilize and craft hands-on art projects. The museum does provide the art supplies. Make sure to check out their website as well because the museum hosts numerous events and screenings each week for the public to partake in. If any of this tickled your fancy, head on over ASAP. Stay tuned for our next segment with BAMFA coming out next month. These segments will dive into specific exhibitions and those behind the scenes who put in the work to present them to the public. Reporting for CalTV Entertainment, I'm Nicole Rogalski.