So I want to talk about why Kubernetes should be boring and how Red Hat is helping make that happen. So I don't mean this kind of boring, even though this is roughly connected. So this is about infrastructure. Kubernetes is infrastructure. Infrastructure helps us build things. But the goal of infrastructure actually isn't infrastructure itself. It's what we build with it. It's how our users and our applications work better with it. And so if I'm a user who is using a service or using an application, exciting to me means, OK, you got a new feature. As a developer, exciting means building my application. But if I'm running an application for a user, exciting usually means something a little bit different. It means everything is on fire again. So in my opinion, if we want happy users, Kubernetes needs to be boring so everybody above the stack can rely on us. Red Hat helps build boring software. There's not open sources and always an exciting thing. People have to chop wood and carry water. But the end result is an outcome for everybody that's better than if we all worked alone. So rather than get all high level, I'm going to get really concrete. Red Hat runs hosted Kubernetes because you should never ship what you don't run yourself. And so one of those variants is OpenShift Online Starter, which is free Kubernetes for everyone. It's a multi-tenant hosted Kubernetes. These are some of the largest and densest Kubernetes clusters in the world, if not the largest Kubernetes clusters. And of course, when you have very large, dense, free Kubernetes clusters, they're very exciting. So one of the things I want to go over kind of what we've done to help make Kubernetes a little bit less exciting in this respect. So events are a very important part of Kubernetes. They communicate when something in the system isn't working. It's actually a breadcrumb for a user to follow to know why their application isn't working. But when you have lots of applications, odds are most of them are, well, maybe not most of them, depending on how good you are as a programmer, some of them are broken all of the time. And so in Kubernetes, we were sending too many events. We found this because we love Prometheus and we use Prometheus from the open source community to make Kubernetes better. This graph is showing you all of the incoming API requests to Kubernetes over a period of time. That giant green bar is events coming from the applications in the cluster that just aren't working. And we also found and fixed a number of bugs in Kubernetes that make metrics better at communicating back to end users. So the fix was actually pretty obvious, which was you don't need to send the same event 32,000 times. You just keep it on the client side, build them all up, and send an update every now and then, hey, your application's still not working. And it's also set the stage for longer term changes that we're making to Kubernetes to make Kubernetes scale better, to make events better with other people in the community. As these clusters got bigger and bigger, though, we started to hit the limits in the system. So the example for us is secrets because we have a very dense multi-tenant cluster. Everybody has their own secrets. Those started to add up. One morning, we woke up and realized that every time one of the servers started up, it was fetching 800 megabytes of secret data. 800 megabytes of anything is pretty bad. And we were doing it pretty frequently. So this trickled through the system. There was a number of bugs found and fixed. We set a long-term arc for what we were gonna do to make Kubernetes better. So the next person who hits this is gonna benefit from features that we've put into Kubernetes that make it work at higher and higher scales. But we also got to pay down an investment that's been building for years. So Kubernetes has been built on LCD since the very beginning. And in the very early days, we worked with the LCD community and team to set a direction for LCD that would meet where Kubernetes would be three years from now. And for us, running in these very large dense clusters, we realized that the time was right. But it's a very complex process because you need to do a migration. Migration is critically important, and we should never, ever as developers, give our end users something that we haven't tested ourselves. And surprisingly enough, giant complex dense clusters are a really great way to test migration. And so we helped triage, fix, and identify issues, and move those out into the community so that everybody can benefit from it. And the end result for us was huge. We dropped memory use on our large clusters down to a third of what it was before. CPU dropped significantly, and API latency dropped as well. So unfortunately as well, when you have lots and lots of applications, you tend to hit almost every edge case that could ever exist in any bit of software. All of these applications fighting against each other, claiming for resources, people coming and going, walking away. Those edge cases we found and fixed. This is one particular example of we enabled cron jobs too early, and an enterprising user turned it on. Well, it ended up creating and deleting about 40 pods a second. And so through Prometheus and through the other operational tools that we developed around Kubernetes, we were able to spot this, go and make those fixes possible. So I could go on. We've done a lot of work in Kubernetes to make it better. But I actually would say, it's really much more important that everyone here recognizes that we as a community need to make Kubernetes boring. To make it boring, predictable, and reliable in open source, because at the end of the day, the only thing that matters is our users. So please come and be boring with us. Thank you.


Were you surprised at his response? Was there anything there that kind of got you? How's your relationship with George Carl? F*** George Carl, for the first time in a while. It's made me sad. It disappoints that I could get a person that angry. I want to love my players. I want to care for my players. But I am also the leader and the policeman of my team. My response in that game, I don't think was out of control or unusual. I was doing something I thought I had to do for my team. I might have been wrong. When those things happen, you want to move forward. You don't want to go backwards.  Canyon is the competitive SOB, tough and difficult to handle. His first team is, and for the other team. But he played the right way. He played the win. And the many of the wins here was because he was the nucleus of our defense.


I'm speaking to a foreign university, right? I'm speaking to Brown, and I'm speaking to Indian students in a foreign university. And I was asking myself this question. I was like, why am I not speaking to an Indian university? Just now when you were talking, I was like, why am I not doing this to an Indian university? And the answer is, I'm not allowed to. I'm actually not allowed to speak to an Indian university. If I try to do this with an Indian university, the government says, you cannot do it. And they threaten the vice chancellor, they do all that. So that's also a huge part of the democratic space. I would love to have this type of a conversation with Indian students in India. But as a politician, that would be something I would love to do. I would love to hear what they say. I'd like to listen to their criticism. I'd like to understand what they're saying. I'd like to inform them of what I'm seeing, but I'm not allowed.


Okay, everyone's here. Hello everyone. I'm going to give a very unbiased and unbiased view on React Native. So let's go over what we are going to talk about today. So for those watching at home, this is a tech talk at Pivotal Labs. So in Pivotal Labs Singapore, many of us have already tried React Native. And so everyone has their own opinions about this. Feel free to chime in whenever you want to agree with something or when you don't think that's the best way to do something. Not at home, but maybe like YouTube comments. Exactly. Okay, so I'll be going over the motivation for React Native. Why do we need yet another JavaScript framework to do something? Just a quick look under the hood. What makes it special? What makes it different? Some of the top features which I've come to love and where I feel React Native lacks and I'd love to see some more development in those. So Native apps, there have been over 200 billion app downloads when you put together both the stores, just Apple and Android. For whatever reason, which I'm not going to go into today, whether Native is the way to go or not, people like Native apps and they have their own use cases. Whenever clients come to us, they want us to build. There are a lot of clients who want us to build native iOS or Android apps. And most of the time it's like they want both. So they need cross-platform native apps and they do matter. What makes native apps different from, say, websites is that they are fast and responsive. They handle complex gestures and you have a consistent user story. Basically, the feel of the app is consistent across each platform and which is not reproduced by a website. But the main problem is when you want to target two different platforms, it turns out that building these apps is really hard. So when you're building cross-platform apps, you have different text apps for each platform. So Android has Java, iOS has Swift or Objective-C. Everyone knows this. There's no code sharing unless, I don't know, you're using C binaries or something. I don't know. And the other thing which is one of the main problems with using just native apps is that there's a slow hydration speed. So as the apps become big, you need to wait a while for compile times and testing on physical devices. It becomes harder. And there is this delay from changing a file to seeing it on your device. Who has already solved this? Web technologies. So for each of these different text apps, web technologies use HTML, CSS, JavaScript across all browsers. So you have the same code being used and you also have very limited build time. In most cases, you just change your file hit at five and you see the result. Again, there are problems with that site as well, but it's got this part right. And so it begs the question, why don't we just use mobile websites or wrappers? So what's the motivation for using native over creating a native wrapper around the web? Again, it goes back to the same thing about look and feel, the consistency across the platform. So these are just three small examples of the same basic navigation in the two platforms, iOS on the left, sorry, Android on the left and iOS on the right.  And other one, which is more subtle is the interaction. So if you notice this one, it's basically very similar, but the way they behave is different. If you put the Android version on an iOS device, the users can tell, even if they're not able to point and say, okay, this is what's different about this app, but there'll be something wrong about it. And this is the main challenge that mobile web faces. So native still has better performance. Mobile websites don't have complex testers. So you have basic touch and drag. Yes, sure. What am I looking at here? Is this a web app? Oh, no, this is the same list view interaction. It's actually implemented. But this is inherently it's inherently using the native version of the list. So it is, but what I'm trying to focus here is if you look at the drag gesture, you see that the interaction is different. One, the whole list moves down. And then there's a different kind of spinner. And Android is something else. You see the list doesn't move. This is very small subtle change between the two. And it's really hard to customize your web app to behave differently in these kind of small ways across different platforms. We want it to look like this. Exactly. This is what we want. This is what we want to achieve, which is hard to do with just wrappers, right? So other reasons is that you can't use native components. So Android does a good, great job with its calendar widget. So you can choose a date and all that stuff. And it's familiar to people. So when you're picking a time on Android, it shows up a clock and you can select drag and drag and select the time, which is a familiar interaction for people who use Android. And if you put that on iOS, it will not work. So if you want to use native components on websites, you need to make JavaScript mockups of these and try to achieve this, which is not really great. It's not a good experience. So what React Native is trying to do is get the great developer experience of developing web apps and apply it with native components. So you can build amazing native apps. And that's React Native. It's, as the name suggests, it uses React as its JavaScript site and it runs natively on your device. So let's quickly look under the hood. How does it work? This is just going to be an overview. So feel free to stop me and ask me more questions. I'll try my best to answer whatever based on what I know. Before we get started with the native aspects, let's talk about the JavaScript site, which is React. So this is common knowledge for both, this applies for both React Native and React and how the code is structured. So in JavaScript code, React is divided into different components. So React is a library that uses components that have props passed into it, which is some form of data, and internally contains state. And what React ensures is that there's a unidirectional data flow. So as you can see, data flows from top to bottom. So each component internally has a render method which it can call, it can render its children, which can be other components as well. Whenever a component state or props or anything in blue changes for that particular component, it calls the render method again. And this render method will internally re-render itself and its children. So that's basically the logic behind React Native. Can the state change without props changing? The state can technically change without props changing if the component is making external calls or something, because state is controlled by the component. Props are something external that's passed into the component and it's immutable. So that's the logic behind React Native. What this enables is, yeah, go ahead. How does components that visual that you like in components or? They are visual components. They are meant to be visual components, yes. So each each component has a view attached to it, a render method attached to it. And the graph, are they nested or? They are nested. So it forms a tree. We'll look at that and go ahead. Yeah, yeah, yeah. So even if you look at the implementation of the router, it is also just another component which has more components in it. Okay, so every render method needs to emit a virtual DOM. So the virtual DOM generally translates into HTML and even the router, it will have different tips which will be ready. So there is, even though there's nothing visually changing on the page, there's still a view component attached to it. So let's look at that. I'll dig deeper into rendering. So this is what a render method normally looks like. That's a bit hard to see, but let's hope it can work. Render is, the key thing about React is that render method is stateless. So it has no side effects. It only operates on data. It's a pure function of data. So here, this dot props are labeled. It's the data that's passed into this component. Similarly, this dot props or conflict is a function that's passed into this component as props. If you see this, it looks something like HTML tags, but it's called JSX. We'll look at that in a bit as well. But what it does is that if you notice, there's nothing else that's changing in here. So whenever there's a prop change, whenever the label changes or the on click property changes, it will change what's the output of this render method. But nothing else can affect the render method. So that's what, I mean, by stateless rendering. This example can also use state. It does mean, but I'm guessing it's just using property strength. So by stateless, I mean the method is stateless. The component might not be stateless. So really, the render method is a function of state and props. Yes. That's what I mean by data. So if you go back to the previous slide, anything in blue is data. So either state or prop. Is it worth saying that the render method is pure? Yes. It doesn't have any side effects. It's a pure function. Yes. Go ahead, Simon. Yeah, but on the next slide on the render method there, so this doesn't explicitly state that this is a react method code standard, but the tags in there, the layer correspondence to UI widgets, native UI widgets, can be the way you should compose the actual layout of your UI by substituting the text and UI components. So basically the render method looks very similar in React and React Native. The only difference is that React deals with HTML stuff. So instead of having view and touchable highlight, you'll have H1, H2, P tags, those kinds of things. In React Native, it provides a different kind of token. So you have things like view and touchable highlights, which are then provided by React, which translate into native views in each of the platforms. So in the documentation, there's a list of tags that they already provide. Those are what you can use. They tell you about the tags, and you just tell them it's a tags metric. Yeah. Yeah. Not always, actually. They don't tell you what it always marks because some of these, like touchable highlight could be a JavaScript implementation. It's just that this is a box. Any click in here will trigger some call on JavaScript. So it needn't be that this touchable highlight will turn into a button element or something in native. It somehow manages. So in native, there's some code that's rendered, which you don't need. It's abstracted away from you. So you don't need to worry about it. Which, let's see. So the output of this render method is a virtual renderer. So the JSX in React, this is some, it's like syntactic sugar. So this is using this. So this is actually for just React, not React data. But it works the same way. When you pass it through a Babel transform, this is what it comes out on the other end. So it's React.createElement div, which contains children, image, and h3. So as you will see, each of these tags translate into a React.createElement. And what this createElement does is it creates a node in the virtual DOM. So just a quick overview of virtual DOM, it's just a tree structure which is created in memory to represent what the document is supposed to look like. So whenever a render method is called, it creates a new version of the virtual DOM. And then it makes a comparison against the previous version. And if there's any change to any of these individual nodes, then what it tries to find the minimum number of changes to make to the previous DOM to make it look like a new virtual DOM. So that's how it tries to optimize its performance. But essentially you could think of it as every time there's a new virtual DOM, the actual DOM looks like the new virtual DOM. How it happens is again abstracted out from. So yeah, another thing to notice is each node that's created here has one parent and multiple children. So again it's a proper tree structure. So if anything changes at one node, that particular node and its children are affected. Now let's look at react-native method. So react-native takes all the react stuff that we talked about so far and puts it in a JavaScript engine which is running on a single thread in your device. There's also a native thread which is the UI thread and that's used to interact with, like it captures all your events. For example, there's a touch. So if you click on something on your screen, it's actually captured by the native thread which captures the event and passes it on to JavaScript. The bridge is some form of inter-process communication so that it can send whatever information it captures here into JavaScript asynchronously so that the UI thread is not locked and it appears to be pretty smooth. In JavaScript, you capture this event. You figure out what components are affected by this touch. You look at your virtual DOM and see which nodes are affected. You pass that particular touch processing into that component and see if anything changed in the render method itself. So the question is missing you, is that the developer's job is just like this path strategy or is that react-native does that for us? Yes. So actually you don't even need to subscribe. So as soon as you create one of these things like the touchable highlight that I showed you, it has a native component running on the UI thread already. So it knows how to talk to its JavaScript process. When you're writing a bridge you might need to be able to do that. I'll show an example later. This is really interesting. Is that literally two different processes or two different threads? Two different threads. But it could be two different processes as well. When it's running in your device I think it's two different threads but you can extract it out to do different processes. There needs to be some interface on both ends to know how to transfer the information with each other. So when you're doing debugging, especially it's two completely two different processes, I'll get to that as well. So again, it creates a virtual DOM, it makes a diff of the virtual DOM because of what native components needs to be changed and makes those individual native calls back through the bridge into the native side. So in case you're using iOS it triggers UIKit to make some changes, Android also has the Android UI. So it uses the native libraries of Android and iOS to make the visual changes that you see on your device. JavaScript, an interesting thing that I found out while I was researching this is that in iOS it uses the JavaScript code that's already part of your device. So it comes with Safari, right? So JavaScript code is what Safari uses to render the pages. In Android it also uses JavaScript code and this is actually bundled with your app as a library. So this means that the minimum size of an Android project is somewhere between 3.5 MB to 5 MB because this additional JavaScript library is packaged with your code each time. Thank you Android. The thing is each Android device has completely different like some have Chrome, some have something else. So you need to have a standard way of processing this and they chose to stick with JavaScript code. Exactly. So this is something I found yesterday. So next thing is let's talk a bit more about the bridge. We know that there are two different threads running, right? So it needs to become asynchronous. That makes sense. But it also means we can't use a single object anywhere and then just keep mutating it because if there are multiple cause happening there could be race conditions. So it needs to be immutable. It's also a serialized interface. This is actually a really cool feature of the bridge because one, if you're developing react-related plugins it is possible for you to capture this serialized information, record and replay them for testing. So that's actually a pretty cool thing that you can do when you're building react-related plugins which talk across the bridge. So the bridge is an object that's immutable? Bridge is just some form of communication. The adapters on both sides. It's just a representation here and the adapters talk to each other using some kind of serialized data. Serialized data is something like, it looks very similar to JSON. So it passes data. It tells you which elements need to be changed, create this bottom node, make this thing disappear. Those kind of calls. So there's a serialized interface that's passed. So is bridge actually a program that's sitting in the view? No. It is just a way for me to represent there is some communication between the two. It's an architectural concept. So if you wanted to write your own custom text you'd actually have to write and write on both ends. Unless your custom tag, if your custom tag doesn't depend on pre-existing tags and you want to make something that's completely new, you need to create something. Another cool thing about the bridge is that the processing is batched. So if there are calls that are faster than 60 FPS, they batch the calls together.  All the calls that are going through between these two threads are batched. So what the bridge, information passing through the bridge looks like is essentially just an array of different serialized objects. So one example of asynchronous execution is that when you have a remote debugger which we'll look at later, you can still interact with this thing while JavaScript is paused. So that's something that I found pretty cool about. Another thing I want to talk about before we start looking at some code is styling, which I'll show you some more in a bit. This is unique to the app native. It uses JavaScript to style everything. There's no CSS. So there's a custom implementation of Flexbox which may confuse people because there's a Flexbox for HTML and CSS as well but this is completely different and the same tags don't apply. So if you notice it's just a hash containing different objects. Something cool about this is you can have like if conditions and all that stuff in your styles. Though I wouldn't recommend you do this. So this is more powerful than SAS. So that's just an overview of some things that's slightly under the hood of React Native. Any questions? Not let's look at some code as it. So I'll start off by showing some of the things that I find really amazing about React Native.  And sometimes it doesn't even work. It's hot reloading, for example, is a feature that is really buggy when you're working with React or any other for that matter. React Native is really cool. It comes in with its packages, it comes in with babble, everything. So out of the box, it's ready to go. So these are the four commands you need to run to get your Hello World app running on your Android device. That's it. Like if npm is fast, you can get it done in under 60 seconds. And that is something that is just amazing about React Native and more frameworks need to do this. So let me just show you what running these commands looks like. Okay. So technically I've added a few more, like two extra folders in here, but imagine that source tree doesn't exist. Everything else you see here is what comes with running those four commands. You have an index.android.js and index.ios.js. That's a package as well. In the package, you will see... Let me make this a little bit bigger. You'll see that all this one depends on is React and React Native, nothing fancy about it. Come on. Yes, this is like the app manifest. This is a package file. Anyone who's worked with npm modules before will find this extremely familiar. Along with this, you have your android.js, which is your root file entry point for Android. And similarly, you have the same thing in iOS. It's literally the same code. There's no difference between the two right now. So this is basically the structure which I was talking about. There's a class called React Native counter, which extends the component, which is provided by React, and it has a simple render method in it which creates another thing called counter. Did you generate this when you made the app, or did you write this? This class is generated. I just created this counter thing just so that to make it look a little bit better. By default, it just says hello world, and these are the files you have to change, and this is the documentation you can look at. So you wrote this React Native counter to illustrate a little bit more with the default app generation. Yes, yes. By default, everything except the source folder comes with React Native, and that's amazing. By default, everything starts working. So let's look at this. Once you have initialized one of these projects, all you need to do is npm start. This one creates a package. This is not using webpack. React Native has its own package, and it listens to port 8081. And if I go into iOS, I just have to refresh. It loads from 8081. It says, okay, there's a request here. It's trying to find an index.ios bundle. The platform is iOS, and it's in dev mode. It's finding dependencies. It's packaging everything, and that's it. That's all there is to it.  Everything you see in here is native. That's interesting. So it actually boots it by loading it from its own... Was that a HTML or web page resolver or something that loaded? Because it looks like it boots that itself of the server. The way that you guys have been streaming a copy of it in the office, it protects itself of the server? I don't really get the question. No. It's running in dev mode. I'm running it in dev mode. We're probably running it in things like that. The version of the app that is deployed to the iOS simulator is looking for stuff on its files that are going to be populated. I'll talk about that in a bit as well. But the cool thing is this iPhone emulator is just running off the code that is defined in here. So this is the iOS package that comes inside ReactNet. Let me show you that. When you ran it, one thing it did was it built an iOS excellent project. When you do the initialization itself, it creates it. So there's this export project in here, which you just open in Xcode and hit run, and you get an emulator running your code app. It's that simple. In the next code, what does it actually run? Does it stand up? I don't understand what actually happens from the... What it does is it creates an iOS app with all the things in the native site, installs it onto your emulator, and then that emulator talks to the packageer to find what are the JS files available on your device, in your application. Does it do an interpreted runtime translation of the JavaScript, or does it do a transpiling into native code? Nothing. So this goes back to the bridge that we talked about. So JavaScript is running as JavaScript in a JavaScript engine. So this thing is pure JavaScript. And the output of the JavaScript is a virtual DOM, and the list of changes that need to be made to the native app to make it look different. For example, when I click increment, it says, go to this particular text box and change the value from 6 to 7. And that's the command that is passed across the bridge into the native site. So that's what's really cool about this, and it differentiates this React native from something like PhoneGap. But PhoneGap, the native site is just basically a glorified web browser. In this one, it's really JavaScript driving the native code. So that's what makes this stand out. So the view of all that is moving your own JavaScript and your new JavaScript. Yeah. That's it. So only the right-hand side has to change that. Yeah. I'll talk a bit more about that as well. Go ahead. So would I be correct to say, if I go to my package JSON, if there is some random JavaScript library or any independent module that provides, let's say, email validation functionality, I can just pull that in. That will actually be usable in my application as the JavaScript. Just call it that. Yes. Though there's a small thing to remember, many JavaScript libraries assume that you're running in the browser, and they access browser functions. If you do that, it's going to fail, because right now you only have a JavaScript engine. There's no DOM. And this is a problem we commonly face when you're working with NPM packages. Well, I think it's implied if it's targeting nodes specifically in front of your process. Yes. Yes. There's no multi-threading on this. They have to be purely abstracted by these. Yes. So something like Lodash works perfectly. But if you want something, say, that creates WebSockets. And you need it to be specific about the API. Yes. Yes. Yes. Mm-hmm. So let me do the same thing for Android. So all you need to do is you need to say ADB devices. Make sure that an emulator is connected, and then I just do React Native run Android. And that's one command. It packages your JavaScript files. It packages whatever is there in the Android folder of your code. And then runs it in an emulator. Runs it in a similar way. Yeah. You could. Yeah. So this will look familiar to anyone who's using Android. That's a same code. Yep. So now going back into, you know, the next really amazing feature about React Native is cross-platform code. Right? You are still using native components, but JavaScript code is able to talk to both platforms. It's amazing that it can use the same file for both platforms. And also you can have overloading. So let me show you what I mean by that. So in code, right now, this one, which is my index. Say I'm going to look at the iOS one. Index.ios.js, it is calling the counter. Counter is inside my components. And if I look here, all it does is it has this thing where there's a text that renders this.state.count. And then there's a button that says onclick increment. And all increment does is it increments the state. That's all it does. And the same code is running on both iOS and Android. Index.counter.js is just one code. But on the other hand, button, which is a custom component I created, has two versions. It's a button.ios.js and button.android.js. So let's look at the iOS app running here. So button.ios.js. I go in here and say it says props or label from iOS. I'll change this from this to say hello. Save this. And yeah, what happened? It is on by default. But maybe let me show you. Enable library load. It's not on. So anyway, I'll just do the regular reload. Come on now. Right? So this is in Dev mode, you have this help window when you shake the actual device. In iOS simulators, you can just have a shot. It's basically the same thing. Okay, so what hot reload is supposed to mean is that when you have DOM and you're changing just one part of the DOM, just that part is switched out. That component is switched out. Yeah. Yes. Actually, I can show that. So look at this. So right now it is this five and says hello Pivotal. And I do a refresh. It loses its state. Right? So now I'm in at six. And then I say hello. And then I save this. Okay, this is still lively. Okay. Yeah. We need to enable hot reload. There we go. So I'm in six. And then I go here and change in word. It changed the app. It changed the view without messing with the state. It's not doing a full view. Yes. Same thing. So I go into my styles and I can say, hey. I just saved. And this is something you can't do with native apps. Yeah. Yeah. Yeah. Yeah. Good work. Just abuse change. So in iOS, I go in here and say, where's the text? Oh, sorry. Counter.js. In increment, I will say instead of plus one, plus two, plus two. Right? Now when I click this, see? So it basically changes whatever JavaScript you change. And there are some weird edge case bugs that I've seen with this, but most of the time it works pretty well. And I'm really happy with that. Just to speak to cross-platform. But with platforms, what about the third platform? With Windows phone? Nah. Windows has a phone. Microsoft is just the opposite of that. They just remove it as an option. They might have. Yeah. They might have. I don't know. So. Cross. Yeah. Does it work when you create new components? Not always. Sometimes, okay, the thing is I have seen that sometimes the package does not work. So when you have a new component, the Watchman instance that's looking at file changes doesn't realize that there's a new component. Sometimes it doesn't figure it out. And you might need to restart that. So if you reach a part of the watchman thing, so whether the watch will become the default. So I think that it does sometimes. But sometimes it does by the watch. Yes. So it should figure it out. Basically, the use case, it's meant to be like quick changes. Like you make style changes or you change the text to make it, what would it look like on each of these devices? You can have three, four devices running and then you can try. And you can also use this on a physical device. So Android, if you're running it on your actual device, you can still link it up to this and hot reloading it to work even on your device when it's remotely connected. It's a kind of... Yeah. But... Yes. So in the past, this might actually be a problem if you work with it. It emulators on faster computers. I worked with it a few years ago. Pretty slow. Okay. The Android emulator. All the emulators were really, really crazy of all this memory. Yeah. How is this one? Is this one faster? Is it still a problem with the emulator being slow? Is it still a bit too low? Not too much. Not too much of a thing. It seems... Okay. But the thing is... Is it okay because of technology? Have you moved on? Or is it because of React Native? I don't think React Native in any way with emulator performance. But in general, for Android, we found that working with an actual device was always better. Yeah. So the emulator is better than the hardware. The hardware does help with the emulator performance for each and you don't have to re-generate it to get rid of the whole thing. Yeah. So that way... You don't need to keep hitting run. Exactly. Yeah. So... Basically, that's what this is. So, yeah, this is an app developed by Facebook. It's for their F8 conference. Even though they look really different. The left one is for iOS and the right one is for Android. They look really different. Most of the code is reused. If you will notice that the schedule in my F8 and all that stuff that's seen on the sidebar for Android version is at the bottom for the iOS version here. So it's just a slightly difference and the bridge component it's using to render. And by doing this, most of this stuff, which is like the scheduler stuff, it's the same thing in the background here. And this means that there's a huge amount of code reuse between the two platforms. And... I don't want to demo this much. Yeah. That's how you feel when you just change something and it actually changes on your phone as well. And you can have multiple devices connected to the same package. Next thing, this is also really cool. So let me show you on the simulator. I come on here. I say I want to look at my inspector. Click on this and it tells me the styling. This is basically like doing development on Chrome. I have like... I have performance analysis to see drop frames or what's going wrong and things like that. And yeah, there's like sysphrase. There's all kinds of stuff you can do. And you can also figure out what state and in that background, what about your state bar? You can use remote debugger for it. I will show that as well. So in-app inspector, really awesome. Debugging. Debugging. That's the next one I'm talking about. This is a familiar thing. You keep clicking next, next, next. You figure out what's happening. Debugging feels like this. So it's a very good feeling to work with React Native. It has these extremely clear error messages.  It tells you exactly where it was called, which file and it gives you these nice colored representation. Yellow means warning, red means error. So let me show you one example. And a lot of times where it actually can suggest a solution, it also gives the... Did you mean this? Yeah, here's the thing. My button expects to... So button.iOS expects there to be two props passed into it. There's an onclick and a label. It says onclick needs to be a function and label needs to be a string. Now, if I go into my counter... Let me show the app. I go into my counter and say my label instead of increment, I want to pass the value... I'm going to... Yeah, sure, why not? There you go. Let me just disable this thing. Hide Inspector. Check this out. It says warning, invalid prop type. It got Boolean instead of string. So you don't need to use prop types. You should talk about that. Yeah, you don't need to use prop types, but if you're using like ESLint or any tool that recommends the right way to... the best way to write code, it always suggests that you create prop types for any data that's passed and gives you like some level of type safety, but this is not the same as compile type. I know, yeah. When you specify it has to be a string again, can you show that code? Yeah, sure. So in the component, which is button, everything about the button is encapsulated here. You have the specs, titles, and the button itself. So here, you have prop types, which say that it needs to be a function or a string and you can say if it is required or not. So if it is required and you forget to pass it in, it will again give up on. What's the button's factor here? Okay, so I don't have specs on this project, but I just added it in there to show what the directive structure generally looks like. That's why you add your unit tests. So is it for... can it have more than one complex? No. You can have a complex one, which just says object. Object is just... It can be a hash or anything. You can be as... You can also say it's not required. So it's either a very specific form. No, no, no. You can have an object of this format where you have these keys. You can have that. Oh yeah, yeah. So there's some level of stuff. And with live reloading, as soon as you're editing, suddenly you see this yellow screen, and suddenly there'll be a red screen if you do something crazy as well. Yeah, but then again, all these things, right, it's the developer's choice to add the properties. So that way, if you're careful, you add the properties. But if you don't add properties at all, then it will not even come clear. You won't need it on this one. So yes, links promise you it will protect us. But yes, links promise you you do not have properties. Again, it's a choice.  Next thing, live reloading. So now, what am I saying? Remote debugging. So click on this. It spins up a debug UI in Chrome. So now I can just look at my inspect and if I look at my console it's possible it's the prototype exception that's causing this. Seems like it's kind of hung. Come on. Android the problem with this emulator is that you can't shake it. So you don't have the options and the newer device don't have the options button on the bottom. So that becomes a problem. Essentially what it does is that in here anything you have like console logs will appear here and how it does this is pretty interesting. It, oh you can have breakpoints here as well. How it achieves this is by making a slight modification to the same diagram we saw earlier. What happens here is it replaces the bridge with instead of inter-process communication, it now uses WebSockets. And your JavaScript everything that we initially talked about the same thing now runs in V8 inside a Chrome app and there's communication using WebSocket. So native code still runs on your device and the JavaScript runs in Chrome. People have taken this to a crazy extent where people have installed this thing in Hiroko and your app can literally stream, every time you touch something it makes a call to Hiroko and ask Hiroko what should I change on my native app. So you can do that kind of stuff as well. Now if you have a library that relies on your web browser of V8 specific features you won't catch that error while even because in work here but not on your native yes I think yeah that's one So do they do anything to prevent that? I'm not aware of that I should actually check there are tests but I'm sure they would have done something like that I need to check, it's a good question. Yes So what you test in the, at least what we use in the debugger mostly was to see what are the props, what is the state and the data is what we do Yes I have not tried it I'm assuming it might but at the same time I can't be sure I need to check Most often what we do is we put like debugger like a breakpoint in the code itself and then just stop there and then look at the objects So I think we're running out of time so let me move a bit faster Next one which we really love is code push It's not technically a feature of React Native itself, it's a library by Microsoft What it does is it deploys your You need to configure for your application to have the code push libraries on Android and iOS What it does is it keeps track of your JavaScript files and every time you publish a news version of your JavaScript components it will dynamically replace the JavaScript files running on your users devices So people could have already installed it and it will live update and that's really amazing One of the, some of the cool features about this is that there's auto rollback So suppose the new version of JavaScript breaks something, it will roll back to an older version unless we do something Then there is segmentation, A-B testing You can also have different groups like you want to have a dev group, you can have a staging group and then you can have production Is this when the guys come to management to live before there is a copyright? Yes It's easy to work with especially in our agile methodology where we use a staging server and we want our product owner to see the latest version of the app instead of sending the new versions of the APK Do you know that that works with React desktop as well? I'm not sure I don't think it supports it right now It's only for Cordova and React Native on iOS and Android So this is a library but also it's not a library It's a service Is it free to use? It's free to use as of now But the big question we have is about the big question is about security and all that which is something we need to consider before we use this for a real client project One shortcoming of this is that if you are making new code that uses native aspects which so that means you are writing code that bridges the JavaScript native views you can't push using CodePush because the native components don't get published Only JavaScript files can be changed So do you know if anyone is using an improvement code push service we'll get basket jfc out of cell phones We'll get basket jfc Is that to be the there are some ratings CodePush makes it super easy to release a new version It's just this one command where you specify your app name and which platform you want to release There are also extra options like I want to release it to 10% of the people over this time period and things like that which is really cool So if you don't want to load your servers for some ways The other thing The other thing We were actually walking around finding people to talk to because it was so amazing We had to spread the word So another really good thing about React Native is that there's a lot of development happening, there's a strong community and there's also backing from Facebook so I think it's worth investing our time learning picking up this language because picking up this framework since there would be growth in the future So next I want to talk about some things I think React Native falls short on and some places some examples where it's not a good fit So one such example is this runkeeper app So this is the iOS version of runkeeper and this is Android version If you notice the views, there's extensive difference between the two views and also I'm sure that they're using a lot of native features GPS, it needs to use maps and all that So in this kind of scenario, what will end up happening is if you use React Native, you'll have to fork each and every one of your files a majority of your files This just ends up becoming very hard to maintain So in these kind of examples when we have clients with very different views across platforms it might not be a good fit But if you think about it in terms of the logical interaction that your component is performing you can probably still share all of the business projects that you're just wiring up to different views But that's For all you know, they probably wanted somewhat similar but because they were different developers it's entirely possible It's entirely possible But where it becomes a problem is if you're using separate views for both platforms and you're using native components there'll be a lot of bridging React Native is only used for your logic So that ends up becoming the next problem bridging code. One of the cool things about React Native is there's native interrupts so you can communicate with Android or iOS So doing that is also pretty fairly simple This is an example where iOS is talking to React Native All you need to do is call this RCT root view and you say that I want to target this one image browser app this is the component and these are the props I'm passing into it So props are also defined here and that basically just makes a call to this one It gets this new props So this is really basic So this is just a very simple example There are also more complex versions that JavaScript can talk back to native code and it can make view changes But the problem is if you're using React Native only for your logic and all your views are written in the native side there'll be a lot of this kind of bridging code and it becomes a kind of overhead Some places where you can't get away from using bridging code is when you want to use custom native components So this is I think it's a stepper counter for Android So if you want to use something like this and this is your setup app setup flow for your app you need to use custom native component The other thing is you need specialized hardware features so you want to talk to the headphone jack or something So this is one of the React Native The JavaScript side can't create new threads It needs to call the native side to create new threads So when you're building an interview in iOS for example you have to extend from the base parts or is there a way of doing So is there a prototype I haven't actually created much bridging code so I'm not very sure about that I'm assuming there might be but I don't want to say that unless I might see a nice native component custom but I don't have to reinvent it because it's inherent whereas if it's something I can import it in then I'm safe and double check and get back to you Okay Can I go over for another two more minutes and just finish it off Last couple slides This is the problem which we already talked about There are so many packages that assume that you're running your code in a browser or you're running it in a node environment and you have all these weird errors that happen because the new version of a library assumes that you're running it in a browser and add some extra functionality This is something that we faced with Firebase which Jason can talk more about as well When Firebase went from 2.4 to 3.0 they included a lot more features such as cloud messaging analytics and all some other stuff which required a browser to be present and that just basically broke support for ReactNet and these kind of things happen because it's not your mainstream when people make huge changes to well established libraries they don't consider ReactNet as one of the platforms they need to support Hopefully things will change but this is something you need to be comfortable handling when you're getting into ReactNet right now One way we have found to solve this is by using this site called JS Coach I can highly recommend this site because they have it's updated daily and it's curated so if something goes out of date and something is not supported anymore in ReactNet it'll let you know and another thing that's amazing is it tells you which of these libraries work on Android and iOS so you can say like I'm only interested in Android so I can choose only the libraries that support Android Those kinds This is a really cool website So those libraries are popular to use with ReactNet? Yeah So Isn't that favorite one? It also has so many React components which didn't show up here So I don't know if it would be better to do something to make it show up here Not sure They're not for ReactNet React also This has to be for React as well Okay I'm going to move a bit faster right now Unit testing is hard for ReactNet The reason being you're testing in a console You don't have access to any of the native components So how do you do this? You essentially replace your ReactNet with a mock ReactNet and what mock ReactNet ends up being is just React So you switch back from ReactNet to React and you replace all your all your native components like views and list views with just divs So it becomes like a tree with just divs in it This becomes a problem because when you have components that contain logic like for example this Recycler, ViewBack ScrollView, you can define things like okay I want to only show the first five and then later slowly load the next few This logic cannot be tested at the unit level, you need to write integration tests for this So all you can do in a unit level is say that hey I expect ListView to be present and I expect ListView to have the props ListView to renderRow which is equal to my renderRow, something like that So the tests you can do is black box tests that say is it present? Yes or no? Are these props being passed into it? Yes or no? That's all you can do So it's kind of limited You can obviously test logic better but for ViewTest this is something I found to be pretty limited And when you go to integration testing there are all these tools that people recommend Appian, Espresso, Xcode, Robotin, all these things are essentially tools for individual platform, Android or iOS You can't write just one set of integration tests that run across both platforms and that is also something I hope will change in the near future, like you can write JavaScript integration tests and that will just run on both devices So with that I am ending my presentation, so I really enjoyed React Native, I found React Native to be very easy to install, to use to debug and to even deploy using code version It's really powerful because unlike other web wrappers you have access to native code, you have multi-threading and it's really fun to use, something What was that? Come on GIF fail Hey This is tutorial We did try to create a wrapper application for a free web store Because all the things you mentioned are advantages and disadvantages, I feel applies equally well to pre-build labs So the main difference is one, you just get this way out which is obviously cool Two, they have a lot of pre-built components that already provide native UI But that seems to be the two main elements, just to list the ASUS and Fedoba and Fedoba has passed the out-of-down job If you build your website right, you can most of your statements So that's where there's a difference in the way you build the application, so when you come into React Native, the amount of effort required will be much higher But then compared to Kodoba apps, because it's not running performance is better, and it feels more native So that is the primary difference between the two, and since Kodoba is also having plugins that can connect to Android and iOS you could technically use that But when you have to work with both your web app and native code simultaneously, it gets kind of mess, here JavaScript is always talking to native and there's no HTML anymore, so it's much easier to work with It's curious if you have verified a thing that becomes messier, because the parts that sounds to me like it would be a messier are the same parts that you mentioned for example you mentioned that it gets messy when you have things in your browser that could be an iOS and Android, that are the parts that would be mostly messy with Kodoba as well, so that problem still exists I mean, when it's vastly different I'm talking about small changes like what we saw, we can have overloaded JavaScript files, right? Yeah, we can look it over too You just have one that runs on iOS and one runs on Android Isn't it the case that if you're going to your app and going to your goal is to have something that is available on the website, in that case for Kodoba whereas if you're bringing an app me, then the app should be available then Oh yeah, I think so There are completely different use cases both the same and whatever Let us think that there could be more of a reuse from doing the rapid defense, but if you have a lot you know the app is going to be all used and you do need performance There's no question There's another point here where when doing a particular device it's a specific version and then you have browser rubbish you've got to deal with that That's a very good point Then you don't know until you deploy to a thousand devices that demand a significant portion of your user base code and you're going to have a free video Other devices that doesn't support 3D versus the one that sends down your iTunes Any left on the wiring and all the stuff that you're going to want to do and you will be able to have people in X number of years bonus problems But the future doesn't have to know about it So, if I want to target both the iPhone and iPad do I have to change stuff? Interesting question I don't know Actually, that's an obvious iPhone and iPad I think that because the iPad has a small way of state there's like a mask When I open it like that I can see that it's like a bar for example So, there are two ways to do this separation of dot IOS You saw the I difference right? You had dot IOS and dot Android IOS Similarly, there is another way to achieve the state but in the final difference actually inspect what device it is and then make that difference So, maybe using that you can actually have a different question Actually, I don't know if you'll go for iPad Imagine if you're using Flexbox So, the thing is when we run it on an iPad it just looks like when you run an iPhone app on an iPad it just looks this like really stretched out zoomed in It's not, by natively I don't think it supports This one? Which one? This one? Oh, yeah That's a good idea Let's see Yeah Hey, it looks pretty okay Maybe, yeah It might be okay to work Yeah, I think it does Cool, thank you Yes, Stefan


Vista visa o dubai vista visa, wich one is better? Hi guys, welcome back to this channel and if you are new to this channel, please support this channel. Consider subscribing to this channel, it's the only way you'll be updated when I upload a new video. For the returning subscribers, thank you so much for coming back to this channel. Thank you so much for watching videos and supporting this channel. Kata visa vs dubai visa, wich one is the best? Hi guys, it's kind of kind of very tricky when it comes to visit visas. But for today's video, I'll only talk from my own experience or I'll talk by the what I know about the two visas, the two tourist visas in the two countries. Remember both countries lie in the Gulf, in the Gulf, they are both Gulf countries and they both have opportunities for whoever learns that opportunity will share will share it to the maxima. But remember when we are talking about visit visas, the two countries differ. First of all, let us try to talk about dubai itself. Yes, dubai has what you call visit visas. You can easily access a vista visa for dubai in case you have someone to apply it for you. Remember, for you to access, for you to get a visit visa from dubai, someone applying it for you has to be in dubai, that will be someone sponsoring you, someone applying for the visa, he has to be leaving in dubai for you to get that visa in the shortest period that you want. But remember, dubai also has opportunities like any other Gulf country, they do have the opportunities because if you have that visa, if you get that visa yourself, the visit visa, you go with it. At least you can get the startup jobs that we talk about. The startup jobs in dubai, like for example cleaning jobs. Yes, we may talk not so much about security in dubai because still security in dubai, you need to go to do what we call PCB, PCB training, you need to have a serial license certificate as a security guard, it is mandatory. So we may look at other minor jobs, like for example look at the cleaning companies, they are very many. At least you can get a setup job which can give you like around 800 dirhams, that's what I can say. The opportunities are there and you can class up the opportunity when you go there. But remember, when we talk about the opportunity, we talk about the opportunity for the person who is prepared to look for that opportunity and the person who is actually ready to take up that opportunity. How do you prepare yourself to take up that opportunity is you starting to prepare yourself and the mind itself to look for that opportunity. Having a passport and knowing what you want and how resilient are you going to get what you want and how resilient are you going to persevere to see that you get what you want or you get that particular job in all options. For example, when you go for a visa, remember you have to move, you have to move area by area company office by company office until when you get that. Finally, if you are so lucky in any way like any other person, you definitely you definitely have what you call, you'll have the job for yourself. Yes, you'll have your job but remember you can get a small setup job which will not require you to incur too much spending. Bed spaces are quite cheaper in Dubai. You can access. There are very many nations from other countries. For example, if you're coming from Africa, you're coming from Uganda, you're coming from Kenya, you can easily find those people that can help you out with the bed spaces and you can live within the means at one moment of time but remember still it will it will it will entertain you, you the person looking for the job to be a little hardworking until you get that job because it's not going to find you on a silver plate at that time. So that's part of what you call the visa visa in Dubai. All right. Hope I'm trying to share up something. You can easily access it. You can go there like any other country, like any other country where you have to look for job. You'll have to fight for it.  You'll have to go there. You'll have to do whatever it takes to drop your CVs, connect with friends until you get that job. That is the visa visa in Dubai. But remember the opportunities are also there. To the start-up jobs, the minor start-up jobs, if you are willing to take the job, if you are willing for example to take up the cleaning, yes the jobs you will get them, whether giving you 800 dirhams or 700 dirhams or even 500 dirhams if you are willing. If your targets at your long-term plans and targets at that time for the first time are not too high, the expectations are not too high, then you can have it and you can access it and you can still have it at that time. Okay, still let us try to look at the Qatar visa visa. Sincerely speaking, if you are planning to come to Qatar, it will not be a very good idea for you to come on what you call a visit visa. It will be quite expensive for you. It will be very expensive for you. Why? Because you will not be able to land the job that immediately with a visit visa. First of all even the requirements for you to come on a visit visa is quite very high especially if you do not have any family relative in this country. That means the requirements are going to be too high for you to have this visa. What is the best option for the best option in Qatar? It is to have what you call a work visa. The work visa you are being sponsored by someone. You have a sponsor, you have a company sponsoring you. Remember, if you are going to come on a work visa in Qatar, you have some company, you likely enough you have some recruitment company that has landed you a job. You know you are not going to have any extra spending of what so have. You will not have that spending. Remember, you will go to a recruitment company that is really genuine. The company that is really genuine for you. It will, let's say for example, going to charge you 4,000 kata rial, that is for all the work visa or the recruitment and transportation for you to come to this company. Yes, that will be your input and your only your only role at that time it will just be to prepare yourself, go for the interview, you are selected, you are sent a ticket and you only have to board the plane back to the company that has already recruited you. Meaning that yes, you are going to inject him depending on the manpower company or the recruitment agencies. I'm talking about the genuine recruitment agencies. Remember, I talked about what things you should consider or what you should know before you travel. What you should know about recruitment agencies. So, once it's a genuine recruitment agencies and you recruited at that, you probably know you'll have a job. It's going to be a job that is going to be hassle free because you already know how much you're going to work for and you already assured that the rest will be catered for. Other than you having what to call a visa and going to Dubai where you'll have to settle less for three months or two months you've not yet found a job or and your visa is maybe three months for the two months you've not find a job, you've not found a job that means you'll have to cater for yourself. But here for the work visa you will definitely be under someone's sponsorship and everything will be assured. You'll only have need to travel and go and start up the job. So, that is what I can say. So, what is my opinion?  It's just going to be expensive. It will be expensive for you. It's going. There are a lot of requirements. They'll require hotel booking, return ticket, they'll require medical insurance but it's also still something that you need to know, something that you need to put in mind that there are also opportunities right now in Qatar. There are very many opportunities. Why? Because of the FIFA World Cup 2022, it's hosting the FIFA World Cup. So, you know that when we're talking about this country or we're talking about it, it also has very many opportunities but have you got that company? Have you really got that company that is going to give you the visa? Have you got a sponsor? Yes, if you well and good you get a sponsor then I think for this time the better idea or the better destination will be you coming to Qatar. In case you get a very good recruitment agency that can get you that job because you'll get that money. If they say they're going to give you 1,000 kata riyal or 800,000 kata riyal, that is the money. You'll hustle free, you'll not pay up a ticket, you'll not pay up quarantine accommodation, you'll not be pay up the medical insurance.  Remember but still if any when you come to this country inside when you come to Qatar there are also opportunities, there are also opportunities within after working a given period of time if you can manuva and change the opportunities that are within but not outside. So to me right now being that we are looking at the peak of the opportunities the peak of the opportunities right now I think it will be a better idea it will just be a very good idea if you can choose Qatar's your destination right now. Yes, tax free money everything but if you want you learn a very good recommend it is that has given you an offer and the sponsor is willing to give you the offer take it take it start with that other than going and spending a lot of money yes you look at the recommend camp and maybe may take around 4,000 kata riyal or 3000 and the same amount of money let's say 4000 dirhams you're going to use to buy your visa ticket going to Dubai providing yourself buying a bed space feeding bus fare moving from one area to another buying a mobile phone air time moving to one place to another is better for this right now I think the better opportunity to be if you can have the opportunity to come to to kata for for the 5th world cup opportunities then well and good that is a better idea hope I've tried to share up something I've tried to share up something guys thank you so much for coming back to this channel and thank you so much for supporting this channel please subscribe to this channel support by subscribing remember if he makes from the makes creation tv support his channel let us grow remember we are looking at around 1000 to 2000 subscribers it is only your support where we are going to to be able to achieve this see again in a next video as we try to see more of these interesting things that will help us to grow financially this information that will help us to grow financially improving our brands and widening us our opportunities in one world remember to follow the SOPs of the COVID-19 pandemic remember to follow the OSPs by putting on the mask social distancing sanitizing your hands because it is the requirement in most of the countries and getting of overall is getting vaccinated because it is one ticket for you to travel as when you are going to planning to travel out of your or your home country is you have to be vaccinated with the vaccines that are rikogana is groble hope after it she up something see you again in the next video


That is Nolan Aronato. Let's go! Hell yeah! Goin' to the Yankees to 99! Jason Dominguez! Congrats on that Yankees! Let's go, dude!


Next question is from Andrew Beth. Are there any common situations where a caloric deficit would not result in weight loss? Yes, now here it is, ready? First of all, if you're in a calorie deficit, your body is making up for those calories by burning tissue. But how can you not lose weight from that happening? Gaining more water weight. This is where you may see your weight stay the same because you're holding more water even though you're losing body fat or even muscle. That being said, if you are in a deficit, your body has to make up the difference, okay? So let me explain this very simple science because I know there's people in the wellness space that deficits don't matter, which is not true. That's so false, it's ridiculous. This is like one law that you can't get around. It's literally a law of the universe where energy cannot get created nor destroyed. In other words, it gets transferred. We can't just create it out of nothing. Shit, if there was a way to do this, we would have infinite energy and become like interstellar being together. It would be awesome. Yeah, it doesn't work. So here's the deal. Let's say your body's burning 2,000 calories. So that's how many calories your body is burning right now, 2,000 and you take in 1,500. How did your body burn 2,000 if you only took in 1,500? It took it from itself. It burned its own tissue. Usually body fat can come from other tissues but it's usually body fat. So if you're in a calorie deficit, you will lose tissue. Your body is taking it from itself.  And this one really messes people up. I can't tell you how many times it would mess up clients of mine because they come back and be like, oh my God, I gained two pounds or three pounds or I lost three pounds. I ate like a crazy over the weekend and I lost three pounds. What does this mean? Or vice versa. And it's like, okay, let's give it a few weeks and see if it sticks because I don't know about you guys my body weight could fluctuate five pounds in one day just from water. So this was something I always knew but I didn't communicate it a lot until I went through those three years of competing and I had to track and measure and I was so diligent about everything so consistently and I saw, holy shit, how much? So I actually got to a place where I was fluctuating nine pounds in the night. So I would go, now mind you, I'm doing a gallon and a half to two gallons of water.  Yeah, 230 pounds. So that's a lot for the average person but it is not that far off like three to five pounds the average person easily can fluctuate and that is a lot.  Totally.  Talk about really discouraging for somebody who's on a weight loss journey and then talk about what a terrible signal for them to be sent to then adjust what they're doing and this is why I became a thing that I started to communicate a lot about. People would, they would all of a sudden change their calories. Yes, and what does that mean? It's a fat. So then that person freaks out that day, they cut their calories even more so maybe reduce it another 500 when they didn't need to. They get on the treadmill now for an hour later on the day and they totally send their body a signal that they do not need to send and they just make it more difficult for themselves in the future. And so you gotta be careful of allowing a day or two of fluctuating, and then you add in things too, like when, you know, if you're on your period, that's gonna change. It's you add in a day where you just drank a little more water. You add in a day where you had saltier foods so you had higher sodium intake. Like all these things can make a difference on how much water you're stressed. You have a stressful day at work so your body starts to retain a little bit more water. So all these factors can manipulate how much water your body ends up holding in a day or not or not releasing. And a lot of times people allow that to dictate what they do nutritionally and exercise wise and then they just make it worse for themselves. Yeah, this is the number one reason why extremely low carb diets became so popular. It was not the only reason, but it's the number one reason because you see very fast initial weight gain with a low carb diet. You don't retain quite as much water when you take the carbs. Oh, right, okay. It's a lot. Every three grams of carbs that you intake your body holds on to three ounces of water. So you take somebody who's eating three, 400 grams of carbs every single day and do the math. You know how many ounces of water their body is not holding onto now? I'll easily if I cut my car, and I don't need a lot of carbs anyway, but if I cut my carbs, I'll easily lose eight pounds within a week on the scale. But I know it's water. I'm not burning eight pounds of body fat in a week. So it's definitely important to consider that. But again, deficit or surplus, me, by the way, when people say it doesn't matter, either A, they're totally negligent and ignorant and idiots, or B, they're confusing what may be happening because, yes, you can change how many calories your body burns, which then makes it no longer a deficit or no longer a surplus. And then they'll come across me like, no, calorie surplus or deficit doesn't matter because I ate the deficit and I haven't lost any weight while your body adjusted, it's burn. So again, the deficit or the surplus, that ultimately it will make or break whether or not you gain or lose weight. So what you're saying is we can't create energy from nothing until we get a Tesseract. Yeah, totally.