Hey guys dampsman sales manager here at Mountain View Dodge in Olds, Alberta today. We've gone in 2017 Jeep Cherokee limited This one's got 66,000 kilometers on it 3m on the front. This is got your full tech package So that's gonna include the adaptive cruise control blind spot monitoring as well as parallel and perpendicular parking Okay, this check the vehicle's got 66,000 K is full leather with heated seats heated steering wheel as well as ventilated seats in the front It also is gonna have the factory remote start You're gonna set a winter tires ready to go. Yeah, dampsman out Mountain View Dodge here in Olds, Alberta


Now here are some matching activities to match the mother animal to its baby animal can you remember them well let's go what is the name of a baby dog is it kitten or puppy, puppy right what is the name of a baby cow is it calf or kid, correct calf what is the name of a baby rabbit is it lamb or bunny, bunny right what is the name of a baby goat calf or kid, kid right what is the name of a baby sheep is it lamb or foal lamb correct what is the name of a baby cat is it cold or kitten, kitten correct what is the name of a baby kangaroo is it eaglet or joey joey right what is the name of a baby chicken is it chick or foal, chick right what is the name of a baby duck or duckling, duckling correct what is the name of a baby bear cub or puppy cub right what is the name of a baby eagle is it eaglet or parrot, eaglet right now can you connect each cub to its mother animal right connect each foal to its mother animal correct well done again thanks for watching my channel have a nice day


Mae'n fawr i'n ddweud o'r cyfnodd. Oherwydd, y gallwn gweld i'n meddwl o'r rhaid yn ymddangos cyd-fawr, mae'n ddweud i'n meddwl o'r cyfnodd. Felly mae'n meddwl i'n meddwl i'n meddwl o'r cyfnodd yn Python i Django, i PHP, i .NET i ddim yn llwyth. Mae'n meddwl i'n meddwl o'r cyfnodd, ond nid oedd yn ymddangos cyfnodd yn rhaid, yn ymddangos cyfnodd ymddangos cyfnodd, bydd gan ymddangos cyfnodd yn wirionedd yn ymddangos cyfnodd o ddigonol i wych yn ymddangos cyfnodd, o ddigonol i wych yn ymddangos cyfnodd. Felly mae'n meddwl i'n meddwl i'r reilau, byddwn i'n mynd fel yma'ch cyfnodd i'n meddwl o'r cyfnodd yn joyful o ymddangos cyfnodd yn gweithgawr yn dod. Felly mor yn meddwl i'n meddwl o'r cyfnodd yn galluiych o boblans bydd wedi cael ei со yncyrgyrchu. are the things that are unique to the problem that I'm trying to solve. And I've just never felt like that about mobile. I've spent time building native mobile applications in Java and Android, and while I quite like the languages, I think the tooling is very impressive, I've always felt like I've spent a very long time solving fairly standard mobile development problems, fairly simple things like making API calls like persisting data things that I assume every other mobile developer has also solved. I feel like I've spent an unusually ar gyfer am ddifodol. Ac if you add to that the fact that realistically if you're targeting native apps at iOS and Android and you have a web version, as soon as you start supporting all three platforms, for every feature you build you probably need three developers to build it. And that's something I've always really pushed back on, that means I've always been the guy sitting at the back of the room in sprint planning saying nope I don't want to do native yet because that's going to mean a big hit to our productivity. And because of that I've spent a lot of time over the last few years looking for magic bullets which of course don't exist. I've spent time building HTML5 web applications and deploying them with PhoneGap, and also trying compiled to native solutions such as Accelerator. And while both have a lot going for them, I've never managed to make a HTML5 web application that actually feels like a native application. It always feels like a web application that's been made a bit better on mobile. And the compiled to native frameworks, while impressive, for anything non-trivial, seem to degenerate quite quickly into if Android do this, if iOS do this, which is hard to test, it's hard to maintain, and loses a lot of the supposed benefits. And that's until about 18 months ago. About 18 months ago, at Cadapult, where I work, we started playing with React for our web applications. And we made a lot of mistakes when we first started playing with React, but relatively quickly, over a few months, we got to a stack that we were quite happy with. We started in converting small amounts of our front-end to it, and very quickly we ported everything across. Now, Facebook sells or kind of put React forward, as learn once, write anywhere, as opposed to write once, run anywhere. And I was kind of skeptical of this, because I've just seen so much of this, if Android do this, if iOS do this type code, for platforms that claim the same thing. But we were very pleasantly surprised when we started working in React. We found that almost everything that we learned building React applications for the web was applicable to React applications on mobile. If you try really hard, it's possible to make exactly the same mistakes on both platforms. But not only was what we learned architecturally relevant, we found that the libraries we were using in React Web, in a majority of cases, we could reuse those exact libraries on React Native. And that was brilliant, because that meant from a developer productivity point of view, any developer who could work on our web code base could pretty much instantly get up to speed and start working on our mobile code base. And that was really exciting. And it's not a very big leap to go from, well, libraries are just other people's code, to why can't we then reuse our own code across platforms? The point we started to get to is that a large proportion of our business logic, so the vast majority of our code, we can now share across completely native applications and our web applications. And the outcome of that, the reason I care about it so much, is that if we want to create native applications and a completely separate web interface, rather than that being three times the effort to support three platforms, it's maybe plus 10% for each of the additional platforms that we want to support. And as a result, I'm no longer the guy sitting at the back of the room going, don't want to do native yet because we're going to need three times as many developers to do it. So I'm Ben, by the way. I'm CTO of a company called Catapult, a staffing platform based in London. I've spoken here a couple of times before, but it's always been about Docker or deploying servers. And while I count myself as a full stack developer, I'm generally much more comfortable setting up infrastructure or building APIs or potentially just bootstrap, or at least up until I started working with React. And the reason I wanted to come and give this talk is because this React and React Native stack is the first time I really felt that the tools that I had made me as productive building front-end applications as I can be building Rails applications. So there are kind of three areas I want to cover, which I think we have enough time for. One of them is just at a high level what does a production React application look like? What are the components of that? Then in a little bit more detail, what are the important considerations for that stack if our main aim is the minimum level of friction when sharing code between a web and a native code base? Then finally, at kind of the other end of the detail spectrum, I've just been looking back over the last 18 months where did I waste the most time? What are the very small things that I spent a disproportionately large amount of time trying to work out? And sort of the things I wish people had told me. And I just run through a few almost anecdotal bits that I hope are useful to anyone who tries to pursue this path themselves. So the first and really important thing is React is not a framework. It's not like something like Angular that includes pretty much everything you need in order to build a front-end or a JavaScript application. React is essentially a view layer. React provides us with a declarative model for defining components. We pass props into those components, so we pass data into those components, and React works out what needs to be rendered to display those components based on that input. So if we're building for the web, that will be React DOM, and it will be HTML that it's coming up with for us. And if we're building for native, that will be native components through React Native. But fundamentally, React doesn't provide any of the rest of the stuff. It doesn't provide a way to make API calls. It doesn't provide a way to deal with persistence. And that can be a little bit confusing when people talk about this is built in React. And what of course is meant by this is built in React is that React is being used as a view layer. And a collection of other libraries are being used to provide everything else. And as a Rails developer, I'm quite spoiled. I'm quite used to the fact that generally for any given component of the stack, if it's not provided by Rails, there is probably a community consensus on, oh, it's your first time doing it, just use this. And the JavaScript world, that tends not to be the case. It was you should use this week and probably this next week. And it's all very, very stressful and very tiring. So what I'm going to go over now is a typical React stack. But I mean, we're not suggesting it's the best one or the only one, but it's a stack that we've been very happy with. It's the one that I've probably seen most used across other large React code bases. And it's one that we found is very, very friendly if your main aim is to be able to share your code base across web and mobile with maximum reuse. So a typical React stack is going to need four main components. It's going to need a router. And a router's job in React terms is going to need, for example, slash login in a browser and work out based on this URL which components need to be rendered. Similarly, in a native mobile application it knows that you are on a login screen and it needs to work out which components need to be rendered to provide a login screen. Shockingly, in a talk about React we're probably going to need some implementation of React. For the web we're going to need React DOM and for native we're going to need React native. State is a little bit more complicated. Now, as we said, React is not a framework. So there is no right way of managing global application state in React. There is no React way of doing it. That said, there are certain patterns that have been quite widely adopted across the community and patterns that we found to be very beneficial and very conducive to this code sharing. This code sharing approach. And you may have heard of them referred to with the flux pattern which is I think the original one or what popularized it. You may have heard it referred to by the name of an implementation of that pattern. For example, Redux, which is my personal favorite of those implementations. And these patterns and these implementations are developed almost as a reaction to the fact in a modern JavaScript application. It can be really hard to answer the question what is the current state of my app and how did we get there? If you imagine in a typical JavaScript application now you may well have a selection of models for getters and setters and you may then have callbacks within the DOM which are directly updating those models and you'll probably kick off some API calls which will also, when they return, update those models and very, very quickly we end up with quite complicated race conditions where it's unclear well was this updated by the button that I clicked first or was it by that API call and almost more importantly it feels very nondeterministic. It feels like each time we do it we can't get something different will happen. We can't replicate that state. And so what something like Redux does is say imagine that our state the entire state of application is represented by a single JavaScript object. In a traditional JavaScript application what we might do if we want to change something in that state is just have a callback someone clicks on something and then we directly manipulate the content of that object to reflect the new values that we want. The problem there is that potentially we can't do it once so it's unclear exactly what the value should be at any given time. When using something like Redux your state is immutable. The current application state can only be changed in one way. The only way to change the state is to dispatch what's called an action and an action is a description of the change that you wish to make to the state. When that action is dispatched you pass that action and the current state of the application can work out what should the next state be and return a completely new object with that state in it. The rest of the application can subscribe to updates to this state so that the UI for example can respond accordingly but it can't directly change the state. This means we have a very linear queue of changes. Everything that wants to make a change dispatch is something and they go through this process one by one. There is some amazing tooling around this approach that allows us to step through that so we can at any point get a completely what is the current state of our application and how did it get there and what's more if we want to we can rewind through that we can step backwards through our state and understand what would our application have looked like at each of these states. It's worth looking at a little bit of an example because this is quite core to the architecture that we've adopted. Here you have a very simple example. Imagine an app which is just one button and you press the button and it increments the counter and the aim of the app, it's an amazing game is to get the counter as high as possible. The app is in the app store. Here you can see labeled as an initial state the JavaScript object that represents our global state. It has a property count which begins as one it has the name of our current user and their rank. In a traditional JavaScript application if we want to update this account we might have a callback for the button and when that's clicked it goes in and updates this object. If we're using Redux we don't do this. What we do is dispatch the action at the bottom. The action is a very simple JavaScript object which has a type property. In this case increment and a payload which in this case is increment by but can be any combination of other JavaScript properties and objects. We then pass these two things the application's current state and the action into this reducer this counter reducer. That's a very simple switch. All it's doing is looking at the type of the action and then working out what changes need to be made to the state. But still it doesn't change the state because it's a new object it merges in the existing state and then makes any changes to this new object. It then returns this this overall object which is the new state of our application. The rest of our UI for example will have subscribed to changes to this and then the next action which is in the queue to be applied will be applied to this new state. So we have a very simple, very linear way of modelling what our application state is. Finally we're going to need something to manage side effects and I found side effects as a term quite confusing just because I'd never heard it before and it turns out that when people talk about side effects I'm fairly sure we just mean asynchronous stuff. So in the case of our counter app imagine that because it's become very popular we want to maintain leaderboards we're no longer doing this just in the app when you press that button we want to kick off an API call which will then update the server and maybe get back the current leaderboard rank of our user. So in this case you would have a library when I'm working with Redux I generally use something called Redux Saga for this and this basically listens for actions being dispatched and then it kicks off something asynchronous so in this case it would be an API call. When that asynchronous action returns it will then generally do something to handle it. Most of the time that will be dispatching additional actions. For example in this case we might dispatch an action that updates the rank value in our state to reflect the user's current rank. So those are sort of the four components that we'll end up with and there will be all sorts of other libraries things are wrapping API but architecturally those are the four big components and so we then have the question of what should be shared and what can be shared between a web and a mobile code base. It's quite important at this point that the reason I was interested in this originally wasn't because I wanted a way to make HTML5 versions of native applications I haven't come across very many production applications where the web version is just a scaled up version of the mobile version so one of my assumptions going into this is that the view layer of a keep doing that the view layer of a mobile application will probably be very very different to the view layer of a web application. That can be anything from the fact that forms which are only one screen on a web application may well be three, four, five screens on mobile to the fact that the entire structure of the application may be different. I'd kind of liken this to if we're working in Rails if we build a web application and want to add a JSON API roughly what we expect that to look at is all of our business logic will be sitting in our fat models or possibly these days in our service objects and then we'll have some skinny controllers some routing and some views which take care of the actual display of that data. We would never consider having a single view for a JSON API and a HTML web view because that would be full of if JSON view then this, if web then this and they're just very different things. I've generally found applying the same approach to sharing code here makes a lot of sense. That roughly means that the routing and the actual components, the view layer aren't shared but the management of states so how does the state of application change when particular actions occur and the management of side effects so things like API calls can all be shared very easily and the bottom tend to make up the vast majority of the code base so the benefits and efficiency from sharing them are quite large. It's worth having a look at a practical example so pretty much any application will have some sort of login page. So to begin with we're going to go to a login page our router which will determine what components to display and then we're going to have the view layer that displays them and these won't be shared. They could be very different on web and mobile. However when you click the login button you're going to be happening. We're going to want to dispatch an action to update our application's global state. At the very least we're probably going to want to update some sort of flag which says that we are currently trying to log in. That way whatever UI we have can listen for this flag and if it's true then display some sort of loading or progress spinner and hopefully at the same time we're also going to dispatch something asynchronous, an API call to actually log the user in. So we're going to have a side effect on the API call. This API call is going to go up to the server and come back. So that side effect is going to wait and it's going to listen for a successful response or a failed response and have parts for handling each. And when we get our successful response at the very least we're going to want to update our state to say we are no longer trying to log in so that progress spinner can be hidden. What's more we're probably going to want to store some extra data we're probably going to want to store a login token for example maybe some profile data about the user and then ideally we're not going to leave them on the login page. We're going to redirect them to a dashboard or a homepage or a terrible game involving a counter. And so the simplest way to do this is we then have our side effect issue a redirect to our router and our router then sends them to the page. And this is the bit that looks really simple but it all starts to crumble and fall apart. Cool. It's intentional but it worked really well. So this is where it all starts to crumble and fall apart because what we have here is a side effect which we said is shared doesn't matter what platform we're on we're always going to want to have something that happens after login. But this side effect is now talking to our router which we said is non-shared. So either this side effect is going to have to have some sort of if web do this, if mobile do this in it or we're going to have to stop sharing this side effect so we really don't want to do this. And as is often the case in the JavaScript world it turns out the solution to this is callbacks. And what we actually want to do is if we go all the way back to the start of this login flow when we click that login button the component containing the login button will also define callback functions it will define on success and on failure and recall that that's a non-shared component our view layer is non-shared so it's fine for our component to know about the router to know how the router works and to know where someone should be directed afterwards. All the side effect has to know is that callbacks will be passed in and they will correspond to a given interface i.e. what parameters to pass in and our callbacks are retained and encapsulated within our non-shared logic. Hopefully what this shows is that in the same way we end up with shared business logic including it in models or service objects in Rails, by following something like this approach where we share our actions and reducers and our side effects and we don't share our router and our components we end up with something that's actually a lot like building a regular React application and this has been really important because we found as long as we follow this pattern we're using the same libraries for native and for web and so a developer who can work on one is pretty much instantly productive in the other one. Now the bit of this slide I really don't like but it seems disingenuous not to include it is in my head this is very or ideally this would be very very clean side effect all was shared and view layers all was not shared and as you can see we have this very artfully faded out side effects bit that goes in the non-shared category because actually there's one particular area and there will definitely be side effects that you choose not to share and there's a sample app I'll share at the end which has an example of this and that's generally native functionality of the device I'm talking about things like if you want to interact with a GPS you clearly have asynchronous behaviours there which is the device's GPS returning new coordinates and it takes a lot of contortion to come up with a way that that should be shared between two platforms because you're never going to need that on web and I wasted quite a lot of time talking to a jurist about it and make sure that this was actually done in a component that was passed to this pseudo shared side effect and the only reason this is really important at this point in the talk is that this makes quite a big difference to how you structure the overall application because one approach is to structure it in such a way that all of the code that glues the libraries together and says which side effects and which reducers and which actions are loaded one approach is to have that as standardised and then make exceptions to it and the other approach is to have a web and native and then find that setup behaviour explicitly which makes it very easy to add these exceptions in when you want to and that will probably make a lot more sense if you look at the example code at the end but if you choose one approach changing to the other one is something of a pain so it's worth designing for that from the very beginning and that pretty much covers architecturally what I've found works and we've found that this is generally quite a productive environment to work in, it's quite a simple environment to work in importantly if you're following a tutorial and there are far more of those at the moment because React Web has been popular for much longer generally it will all be completely applicable to React Native as well and this makes the experience of working on this very, very simple you'll find that less so with React Native so anything device specific obviously won't apply to the web but in general this is just like working on a regular React application there's nothing particularly special about it and that kind of covers the sort of architectural side and how we found sharing works and so the rest of this is mainly about the bits that I kind of really messed up early on, the bits where I wasted a lot of time the first one is that we are building native applications here that means that we do need an Xcode project we do need a Gradle file we do need Objective C code we do need Java code and happily React Native includes a CLI which generates all of this for us very, very efficiently now what React Native will generate is quite minimal but it definitely works and because I never want to try and retrofit a React Native into a web project again even if I'm making a web project if I think there's any chance I want to build a native version I'll start by generating the native version just so all that boilerplate is there and then add the web bit afterwards now the built in CLI generator is fine but very minimal it's completely non-opinionated it is the bare minimum code you need for a React Native app so you really, really have a version to writing boilerplate I really don't like it and there's a fantastic generator by the guys at Infinite Red called Ignite now the Ignite generator is just a layer on top of the regular React CLI so you don't need to worry that it's introducing additional dependency it's not something where if it goes away it will cause problems for your app all it's doing is generating a load of boilerplate so you run the Ignite generator and if you remember the four components from earlier on it will take some of the most popular libraries from those and it will set them up and set up all the boilerplate that links it for you this is not a good reason to use something but it also generates an app folder which as a real developer makes me feel far more comfortable because everything is in an app folder that app folder will probably look relatively familiar you have in there subfolders for things like sagas which is for our side effects for redux which is for our state management for components which is for components really and the first thing I'll do is refactor those into three subfolders the only reason that's actually worth its own slide is because something you may want to do quite early on is take your shared code and turn it into an npm package and if you've done this from the very start it's pretty much trivial to pull back shared code out into an npm package because all your file plans will already be relative everything will already be properly namespaced and that process will take a few hours rather than a couple of days if you're having to unwind this from multiple other places the final one which ended up taking an awful lot of time way more time than I'd like to think about really is BabelRC now Babel is a or Babel can be used to transpile more modern dialects of JavaScript like ES6 into forms of JavaScript which are compatible with much older browsers so if you've used React Web before you've almost certainly will have come across Babel for this process and if you're working with React for Web the standard way of configuring Babel is a BabelRC file in the root of the project and in here you define what transformations should be applied to your JavaScript and in what order turns out order is really really important now React Native doesn't use a BabelRC file it does use Babel but it has its definitions baked into it a workflow I discovered in a very painful way is extremely possible is you will then add a BabelRC file to the root of the project to configure the website of the project React Native if it sees a BabelRC file the root of the project will then use that BabelRC file to the exclusion of all its own configuration so far so good there are lots of tutorials that explain how to set up a BabelRC file for use with React Native the problem comes because React Native has a package which caches incredibly aggressively this is to make so that when you make a change to one file you don't have to go through and retransfile everything in node modules essentially now what it's very easy to do is you make a change to your BabelRC file you test it on web, you test it on mobile everything works brilliantly you commit your feature and move on and days or weeks or hours or whatever pass and then something happens which invalidates this cache and you will suddenly get the most unintuitive error messages you will ever encounter my current favourite is type error no other words on the screen just type error in white on a red background it looks like a meme of some sort and so then you do what any responsible developer does or commits to ones that you knew were working so that everything starts working again but of course nothing does start working again because the change to BabelRC occurred a week, two weeks, three weeks ago and eventually you consider scrapping the whole thing of becoming a plumber or a carpenter or something that doesn't involve working with JavaScript and the solution is painfully simple whenever you make a change to BabelRC start the React package manager with hyphen hyphen reset cache then it will break immediately and you will know that your problems occurred BabelRC file true story now hopefully what I've kind of covered here is the higher level architectural staff in terms of what it makes sense to share how you can share it hopefully kind of got across there are some very real productivity gains that we're seeing from this the reason I was so excited to talk about it is this has completely changed at what stage in a project I now think it makes sense to start supporting native applications because I now don't see supporting both web and native as something that is suddenly going to require either a big drop in velocity of features or to hire a lot more developers and to me that's a really big change what I can't really cover in this talk is the kind of detail of how you glue all these libraries together and what that sharing actually looks like so what I've done is put a sample project up at talkingquickly.co.uk forward slash RailsConf 2017 this is a personal project that I've been playing with for a few months it's a little geologa so you work around different countries and it tells you where you've been and shows it on maps and the important thing is it demonstrates what this sharing looks like in practice and both the iOS and web bits are open source as is the Rails API server behind it so you can get a completely functioning app up and running and play around and see which bits of this approach you like and which bits you don't that's pretty much everything before we go on to questions so we're at Catapult, we're based in London we are of course hiring if you think this stuff is interesting if you're in Catapult.com or Grammy here and get a coffee, we're in London but most of the product team is remote and yeah, come and chat thank you so much for listening this was really good fun, are there any questions? yeah absolutely, a question for anyone who didn't get it is when you're structuring actions is there a way that you need to restructure it when they restructure it from a single file they get particularly big yes is a short one so I'm a big fan, so Redux and a library called Redux Source is a nice syntactic sugar on top of Redux and that pretty much provides a framework for having multiple reducer files and then ensuring that so if we go back to that one you can have 10 or 15 or 20 files containing these functions and it takes care of making sure that when an action comes in it passes it to every single one of those in sequence so you can break this code up and make it very modular so if you do actually need a mobile interface for the web version then what should you do there, is that right? so having said I wasn't originally interested in making HTML5 versions of that that's actually the exact problem I have at the moment because it turns out we also do need a HTML5 version of our web application which is upsetting yeah so two approaches and I'm playing with both at the moment so I'm not sure which is the best one we found is because we tend to use bootstrap as the basis for everything it's been very easy to convert our web interface to be a responsive mobile app there is also a new framework from Microsoft from Microsoft doing loads of really really cool react stuff which wasn't something I would have expected a year ago and they're working on a library which is intended to be an abstraction layer on top of react which allows you to define components and then have it work out what component would this be for web and what component would this be for mobile so if that's what you really want to do if you're prepared to lose a little bit of flexibility in terms of what native components and what web components you can use that may be a solution to that I haven't used it and I also can't have the name of it but if you Google Microsoft React cross-platform it would definitely come up so the question was how do you manage when iOS and Android have very different components how do you manage keeping them separate the honest answer for a majority of stuff generally I haven't come across many React has quite a good job of working out given the react component what the native component should be and providing a common interface across it and I'm incredibly sceptical of things doing that because everything else that I've tried that has never really worked so far React has worked quite well so I don't think we have any production code at the moment where we've got switches for display something different for iOS and Android because generally it's just defaults for how to display this particular control type on each platform and how to use the native components on that platform has been good enough for us so not something we've had to deal with yet happily oh that's a great question so what's the productivity of server-side standard sort of in not a bad way old-fashioned server-side rails versus this client-side JavaScript application honestly I've never found anything that I'm as productive in as making a server-side rails app so I want to make something incredibly quickly rails plus hammel I just find that incredibly fast I think what we've found with this is once you get a few months in so it's beyond the simplest application it's actually swung the other way so it's far quicker to build the first version in server-side rails but having this very clean separation of the API server and then the front-end application has actually been far more maintainable and it's been far easier to do in a maintainable fashion so I think for larger projects I would actually I never thought I'd say this I would tend now towards rails as the API server and sort of some variation of this stack as the front-end and that's because after two or three months I'd probably expect to be more productive in this version than in the server-ended version how much iOS and Android you need to know to start with React Native? Absolutely not I was super impressed even without the ignite generator and so on you download React CLI you will have to follow some of the getting started stuff for sort of Xcode projects and Android projects just installing the SDKs but it actually did just work I never believe it when someone says it just works in the context of mobile development but it really did it generated a project, ran the command and it was up and running in a simulator so you don't need to know anything so is there any element of web view to this or is it native UI components? it's all native UI components that are going on anything, any component that can be used in React Native will generally map or does map to native components and so does have the corresponding feel and generally the corresponding performance and of course corresponding performance for the standard applications that are displaying lists of things and taking data in I'm sure it wouldn't be suitable for making games but for most typical applications that are just taking information in and putting information out it will be providing native components at pretty much native performance any pain points working with React Native I want to really glib and say Android but that's really unfair but yes actually Android to an extent not because React Native is any worse on Android but just because the development process is a bit different because pretty much if it works on one iOS device it works everywhere, if it works on one Android device it definitely doesn't work everywhere because they're significantly different so automated testing and that sort of thing we found are very reliable ways of identifying bugs in iOS applications and in the majority of Android applications but you can't get away from the fact that you need that extra layer of testing across Android devices with different capabilities cool so what's the strategy where you want to do an awful lot of customization in the UI I think on almost two levels to that one is the increasingly and when you look at a lot of the very custom components they're actually just quite heavily styled and generally React is quite good at doing that so you can get quite a long way like that if you reach a point where you actually need to write a completely custom control for that platform this is something I've only really done once sort of a long way for an objective COA Java expert but the program the process for developing native plugins is relatively simple and for making sure you do that in a reusable way and making them testable so it's fairly easy to do if you have to do that but it's not something I have a massive amount of experience with sure so any experience working with the native wrappers for turbo links and what was that like working with what how does that compare to working with React I've used them in test projects to try them myself, I've never used them in production so probably take anything I say with a big pinch of soul I was quite impressed with them what bothered me about them and the reason I've shied away from using them in production is they just seemed very very niche there aren't a huge number of people with experience using them so just from a selfish point of view in terms of attracting developers there seem to be an awful lot of developers out there who really want to work with React and React native and far fewer who want to work with turbo links because it's seen as something or turbo links native just because it's seen as something that it's not necessarily clear how in demand that skill is going to be in 2, 3, 4, 5 years time so it's not something I've been particularly keen to put into production cool if that's everything, thank you very much


What's going on everyone Sam here with Leighton sports cards, and I am ripping at five 2022 between father's day packs for Terry C. So good luck Terry Terry's first break here with Leighton So welcome to the family Terry. Hopefully we can please some Nassiness on your first break. Let's see it. Got a Lebron base followed by a Torkelson rookie. We've got Julio Rodriguez rookie nice J rod Followed by a Kenny Pickett rookie insert behind that Not too shabby there a couple of really good rookies right there and their respective sports We've got Nolan Ryan followed by a Scotty Barnes rookie. There you go on the insert Not too bad there really good rookie so far Terry. I see something numbered We've got Lamar Jackson on the insert and there it is nice We got a Trey young foil two out of 199 There you go Terry on your numbered card. Congrats, buddy. That's awesome and last pack see what we got in here for you bud a Charles Barkley and a Carson strong on the rookie That'll do if you break there Terry congrats on the hits again. Thanks for jumping in in your first break Yeah, we'll get them right out to you, but thanks again


The study analyzed the physical chemical properties of Solosia Argentia fibr, CAF, through various techniques and found its cellulose content, density, and crystallinity index. Thermal studies revealed a maximum degradation temperature of 324 degrees celsius with a kinetic activation energy of 61.393 kJ per mole, suggesting CAF as a potential reinforcement material for green composite applications. This article was authored by P. Manamaran, M.R. Sanjay, P. Senthemarai Canon, and others.


The STEM Path of the MBA program is a five-year program where every semester you take a one-and-a-half-hour business class.  And so that's a great opportunity and so I'm excited to see what that holds and see what I get out of Manorsen Business School. Being able to combine both the engineering aspect through the engineering department and also having the MBA and the business know how to sell a product and how the industry works from a business standpoint, combining those two together I feel would be really helpful to market myself and also help myself like go forward in my career once I actually have a job. The Great Path of the MBA is a very unique program. I've been in different group projects where I'm partnered with a microbiome major and I know nothing about microbiome but you have to make it work. So it's a really great way to meet new people and to just expand upon your creative approach to learning. It's a unique opportunity that you wouldn't normally get. We take one class a semester through the Create Path of the MBA. I'll take three classes this summer. I'll take another three next summer and then I just have one extra year of full-time MBA classes after that and I'll be done. So I'll get my MBA in one extra year after my undergraduate degree instead of two. It's a great opportunity for students to have here at the University of Alabama. Coming from an art background, it's interesting applying to a marketing position because they see an art background and they say, hey, how does this apply to marketing? But then, you know, within your resume, you can say, hey, I've done all these pitch ideas for businesses. I've worked with NASA patents, you know, all these different innovation projects which really set you apart as a candidate.


It's my great pleasure to introduce Camilo de Lellis from the Institute for Advanced Study, who will talk about the center manifold. The topic that I'm going to explain to you is actually quite complicated and it took me a lot of time to figure out how I could actually convey the basic ideas in this piece of mathematics without entering in too many technicalities. I hope I have succeeded in that. So we are going to actually look at area minimizing graphs. First of all, let me set up a little bit of notation. So we will use this notation for the graph of a function u. So this will be the set of points x u of x such that x is in a certain domain f and f will usually be some subdomain of rn and for our purposes u from some omega which contains f into rn will be always a Liebschitz function. Yes? Right bigger. Okay. Good. Okay. So first of all, let us make a very simple observation. So omega contains f. Very well. So first of all, we will always look at functions which have a certain precise Liebschitz bound. So first of all, we will use this notation for the Liebschitz constant. And secondly, in all our assumptions, the Liebschitz constant of u will be either bounded by 1 or bounded by 2, something like that. Okay? So it's not so important actually. One could figure out better constants. I mean, the important point is that it's always under control with some uniform bound. Okay? And the first observation that we the first observation that we want to make in the lecture notes, it's actually stated in the form of a lemma. And it's not a lemma that I'm going to prove because it's very elementary, is that if we have a Liebschitz function and we tilt the coordinates slightly, so not too much. In the new system of coordinates, the graph of the Liebschitz function still the graph of a Liebschitz function. Okay? So if we tilt the coordinates slightly, graph of u over some set f will remain. So I will use actually this notation for the new coordinates will be actually the graph of the new functions in the new system of coordinates. So here I have my original coordinates and maybe some Liebschitz function and then here I have a new system of coordinates. Okay? So this would be like x and y. Here I have a new system of coordinates x prime and y prime and in the new system of coordinates this will remain the graph of a new Liebschitz function which we'll call u prime. So if I take a point over here and I go down over here perpendicularly in the new system of coordinates this will be the point x prime u prime of x prime. Okay? And it's a simple observation that the Liebschitz constant of u prime is actually less or equal than the Liebschitz constant of u plus some universal constant c times the modulus of the matrix whose rotation I mean of the rotational matrix which is giving you the coordinate transformation from x prime y prime to x y. So the coordinates x prime y prime have then the relation that x prime y prime is equal to a x y. Okay? I mean this as long as you have this uniform bound of the Liebschitz constant which is like one or two. Okay? So this is nothing but by saying that since the Liebschitz function I mean the Liebschitz constant of I mean if you had a nice domain the Liebschitz constant is nothing but the maximum slope of the function and if you look at it in the new system of coordinates the maximum slope of the function can be at most the maximum slope in the original system of coordinates plus the angle that the new system of coordinates forms with the old system of coordinates. Hilbert Schmidt norm for a matrix operator norm it I mean it's a matrix so it's an element of a finite dimensional space so pretty much any norm you use actually it's going to make this statement happy. But okay so let's say in general when we I mean in general when I have a matrix and I put these two and I mean I look at norm of the matrix I'm always thinking about the Hilbert Schmidt norm if I'm not saying anything else. So the Hilbert Schmidt norm meaning the sum of the squares of the entries of the matrix and then you take the square root of that. Sorry? Right sorry exactly so the angle sorry I forgot to subtract the identity good point. Yes absolutely I have to change actually that in the lecture notes. Very well okay so thank you very much for the observation so now let me give you a definition so I will consider area minimizing graphs okay so I will define area minimizing Lipschitz graphs by the following definition so first of all the Lipschitz constant of view that's going to be less or equal than two okay and then so here there will be some some constant c0 which depends on m and n and it's positive okay and so for every system of coordinates with this rotation matrix which is close to the identity by this constant c0 so and so if u prime so if graph of u prime omega prime is the description of our surface in that system of coordinates okay then what I want is that the m-dimensional volume of the graph of any competitor v and omega prime is actually bigger or equal than the m-dimensional volume of the graph of u prime and omega prime and this is for every Lipschitz map v such that the place where v and u prime differ right is compactly contained into my omega prime okay and now of course this u is from omega into rm and we actually prescribe that the domain omega is open yeah rm okay so this means that every time that I make a perturbation which is a new Lipschitz graph but I allow my system of coordinates to be slightly changed so then the competitor must have strictly a bigger volume and what is this m-dimensional volume that I'm using so this m-dimensional volume is the usual m-dimensional volume of a surface I mean it might be described as the house of m-dimensional measure of the graph as a subset of the product space and we have a classical formula for this graph for the area of this graph which I'm now going to write down explicitly because it will be extremely useful in a lot of our future computations so the m-dimensional volume of the graph of u over some set omega and actually in this case this omega does not have to be necessarily an open set actually we can make this computation on any Borel set okay so what is this this is this has an explicit formula so it's the integral over omega and then I'm going to take the square root so here I have one plus modules of du squared and then I have the sum and in this sum I have all minors of order two times two so and I have I have to take the determinant of these minors and then square it okay so m alpha beta of du is a or is any k times k minor and our convention is that modules of alpha where alpha is a multi index is exactly the length of the multi index so this means alpha is a collection of numbers which are going to be the rows that I'm selecting in my in the matrix representation of the derivative of u beta is going to be the columns and here I'm selecting k equal modules of alpha rows and k equal modules of alpha equal modules of beta lines and then I take the determinant and square it so this complicated this complicated formula of course becomes rather easy when you have a function which is taking value in the real line because when the function is taking value on the real line this term over here drops and you only have the square root of one plus modules of gradient of u squared okay so this formula gives you the house of measure of the portion of the graph which is lying over the set f okay so it's it's it's a well-known fact that area minimizing graphs with a sufficiently small constant are actually are actually real analytic so this is a fact and we are going to see actually at least a partial proof of this so if u is a leap sheets area minimizing graph with sufficiently small constant then u is real analytic actually in co-dimension one so if your graph is taking value into r into the real line you don't need any restriction on the leap sheets constant and there are several ways of doing this so the most classical way would be if you are for instance in co-dimension one to write down a system of partial a single partial differential equation for your minimizer just by writing down the order Lagrange equation using the Georgian-H theorem to infer that actually the derivative is herder continuous and then use the Schauder estimates to infer sort of further regularity okay and then okay so it's a classical fact that the equation that you get which is an elliptic equation and which is non-linear but it is real analytic in the in the gradient the second derivative any new if it has I mean any smooth solution then will be real analytic in higher co-dimension actually the bound on the lip sheets constant is important so there are examples of solutions of the Euler Lagrange equations and these examples are actually due to Ostermann and to Lawson and Ostermann which are just lip sheets but don't gain any further regularity so they're not going to be c1 alpha in fact of course as soon as you have herder regularity for the derivative you can apply Schauder estimates so if you have c1 alpha regularity even in the higher dimensional case you can carry on the usual program and then get to real analyticity okay so we're not going to follow that I mean we're not going to follow this plan but we're going to prove another theorem of the Georgi in this particular case so it's it's not the most general version of this theorem of the Georgi because the most general version works without assuming that the surface minimizer is a graph but it's particularly interesting to see how the proof actually works in the graph case and then the general case is kind of more technical generalization for which you have anyway references in the lecture notes okay so here's then the first theorem that we will prove in this lecture I mean roughly two of the lectures will take to prove this theorem over here so this is the Georgi's theorem for area minimizing graphs and here is the statement so for every alpha between zero and one there exists constants and these constants which are epsilon zero and c are going to depend on alpha the dimension and the co-dimension of the domain such that if u from the ball of radius one into rn is a area minimizing leap sheet's graph with constant less than one then actually in half the ball u is a c1 alpha function and the helder norm I mean the helder semi-norm of the derivative of the function oh no no no wait wait wait I need another assumption sorry so if it is a leap sheet's graph and very important one quantity which will be called the excess which is the volume of the graph minus the volume of the disk so which we we will denote by omega m so omega m is there a back measure of the one-dimensional ball in rm okay so if this one is less than epsilon zero then as I was saying the surface is actually c1 alpha and the helder semi-norm of the derivative of u in the ball of radius one half is controlled by this constant that I gave you and the square root of this e which we will often call the excess okay so you know this over here that I'm taking the volume of the graph which is sitting over the unit disk and I'm subtracting the volume of the disk so this is so this quantity tells you how much the graph exceeds the area of the disk of course since it's coveting the disk it must have area which is at least the area of the disk and if this excess were equal to zero it's always a good thing to check whether you know the theorem is at least trivially true when you have a trivial assumption if the excess is equal to zero then the only possibility is that the function is completely flat and if the function is completely flat actually the helder norm of the derivative is just equal to zero because the derivative is constant I mean the derivative is actually identically equal to zero in this case okay so you see that instead of assuming that the lipschitz constant is small because here I'm saying actually that the lipschitz constant is less or equal than one I'm assuming in a sense that the oscillation of the tangent planes is not too large in an even in an integral sense right so this is more kind of an integral control okay so that's the george's theorem and let me I mean before going on to state the other theorem which is actually the real main goal of the lectures and which is also an illustration of a much more general theorem in a very simple setting so let me just make the following remark so this is also left as an exercise to you but it's certainly a more difficult exercise than this change of variables okay so we're going to do the same so we're going to do the following so assume this denotes the tangent space to the graph of the function u which is lipschitz and therefore differentiable almost everywhere I mean when I mean actually ignoring the domain of the graph I mean when I'm in this notation when I'm ignoring the domain of the function it means the domain does not play such a big role sometimes I will just drop it okay the tangent space comes with a very natural orientation right so if you take a standard basis e1 em standard basis of rm if you then take em plus 1 till em plus n standard basis of the other factor okay then you can write down explicitly a basis for your tangent space and the basis for your tangent space is going to I'm going to denote it in the following way so it's going to be ei plus the differential at the point p of f at the point ei I mean on the computed on the vector ei and this writing over here is nothing but the sum for k equal 1 to n and here you will have df k dxi of course at the point p sorry oh f is a function and the function there is called u yeah let me call it f actually okay and here I'm putting the em plus k vector okay so that's what I'm what that's what I I understand is this sum so this sum is going to be a vector in rm plus n and as I take i which is running between 1 and em I actually get a basis an oriented basis of my tangent to the libschitz graph which gives you a canonical orientation of the tangent and of course this canonical orientation of the tangent is kind of the only orientation which is compatible with the idea that if the function is identically equal to zero and you are completely fat right so the canonical basis becomes e1 em of your tangent space right so just the basis that we have fixed of the of the first factor okay very good so now if I give a name vk to these okay vi to these vectors okay I can use multilinear algebra and this k vector so I take the wedge and then I normalize by the modulus and I'm going to tell you what is the modulus of the of the of the m vector in a couple of seconds okay so this is what we will call t vector p graph of u so this is the m the unit m vector which is orienting your tangent plane okay and what is this object over here so this object over here has a very neat geometric interpretation this object over here you can define it as the m dimensional volume of the parallel of the parallelogram which is spanned by v1 vm that's one possible definition but you can actually endow the space of m vectors with a scalar product the scalar product being the following so if you have two simple m vector the scalar product between them is simply the square root of the determinant of the matrix that you obtain by taking the scalar products of the various vectors and then this m dimensional volume is actually nothing but the norm which is associated to this scalar product that you can define on all m vectors so I'm defining it only on the simple m vectors but you can actually extend it by multilinearity to all m vectors okay very good so now there is an interesting formula so let me give you this as a proposition maybe it's actually a lemma in the lecture notes so take a leapschitz graph it's just a computation so you don't need actually any bound on the leapschitz norm it's not going to be an estimate okay then the m dimensional volume of the graph of u over omega minus the measure of omega okay which we know by a simple geometric observation is actually a positive number right just because we have said you're covering omega so you only have hope of getting at least as much area as omega so this is actually one half and then you have to take the integral over the graph u omega and here you take the distance between the m vector which is tangent to the graph of u and the horizontal m vector so for which we will use often this notation squared okay and here you're integrating in the house in the house of measure and no no no sorry no no no sorry sorry no no I got I got actually mixed up no this color product does not have any square root sorry so thank you for pointing this out I got mixed up so the modules of the m vector right is of course the square root of the scalar product of the m vector with itself okay so of course the square roots you only you only take it when you're interested in computing this guy yeah yes okay and so what is this pi zero with a vex with a vector on top so this is the notation that we will use for the standard m vector which is orienting which is orienting your horizontal plane okay so pi zero is equal to e1 wedge em okay so now this gives you a sort of explanation why in the estimate I mean in the george's estimate of the c alpha norm of the derivative of u you had a square root of this excess okay so if you interpret it in this way right this quantity this excess is a kind of square of an l2 norm right so this looks like the square of an l2 norm okay so now one of course you can observe one thing if you are a leap sheets graph as soon as the left hand side is equal to zero the right hand side is equal to zero and vice versa because you have this identity but if you have a general surface the thing on the left might be equal to zero and the thing on the right might be actually positive so if a surface gamma so so if a surface gamma let's say for surface sigma a general surface sigma has no boundary in the cylinder omega times rn right which is kind of the situation in which we are working if we have a graph so if we have a graph the situation is something like this right so the boundary of the surface is all lying on the lateral surface of the cylinder so you don't see any boundary inside so in a more general situation in which the surface sigma has no boundary in omega times rn it's going to be a multiple cover of what you have down right but you might have more than one than one sheet okay so you might have for instance several sheets okay then if you have several sheets the right hand side for instance really measures how much these sheets are horizontal right so the right hand side would be equal to zero if these three sheets in the example they're all flat but on the other hand the left hand side is specific of assuming that you have one single sheet because the left hand side is going to be the volume is going to be three times the volume of the horizontal projection then you subtract the horizontal projection and you just have something positive okay so you might wonder whether there is a general the georgi type statement which tells you even if I don't assume that it is a graph and so the surface might be multiple sheeted if I assume that the right hand side the excess written with the moduli is small can I conclude that my surface comes of course not with a single graph with c1 alpha estimates but with a bunch of graphs right so with a sheeting so of a certain number of graphs which will depend somehow on the total area of the surface to start with which are all c1 alpha okay and I mean this is not a you know it's not a generalization for the sake of generalization so if you were looking at general of it at the theory of general surfaces which are minimizing the area for which a priori you don't know that there is a graphical description at any point right because they might be very rough this is the kind of theorem you're actually looking for because since you don't have any a priori assumption that you're locally graphical right so you want to work in the most general situation and now here it comes a very interesting point so in co-dimension one this sheeting theorem is actually correct so in co-dimension one if I have a generalized surface and I tell you that this quantity is small over a certain cylinder and I have a bound on the area of the surface then if this quantity is sufficiently small then I know in half of the cylinder I'm actually a certain number of sheets which are c1 alpha and they are all separate graphs which don't intersect so in co-dimension one this kind of sheeting version of the georgi's theorem is correct but in higher co-dimension is completely incorrect so it's I mean it's it's it's a famous example which is due to Federer and based on the computation of Wirtinger and I can actually I cannot give you the proof but if you take the the following surface so you take the complex if you take the the complex space c2 which you identify with r4 and you take the following surface so you take z square w square equal to z to the power 3 okay so this is what is usually called a a algebraic variety in in in c2 well locally this is an an oriented area minimizing surface so in the sense that it's an oriented surface it has a singular point in the origin but if you sort of discard the singular point it is an oriented surface such that if you replace a portion of this surface with any competitor the competitor has to go has has to have larger area okay it is very flat in the neighborhood of the origin in this sense so you see if I were allowed locally or I am allowed of course locally if z is different from 0 to take a square root and then on top of every z I see somehow two copies and I will see z to the power 3 over 2 so I will have very flat tangents and this quantity will become actually very small now we will see that's the the the quantity that we have to look at is not really this one but it's it's average so if you want the quantity which is really relevant for the epsilon regularity theory is actually the average of this so I have to normalize this by the volume of the horizontal projection but even if I normalize by the volume of the horizontal projection these the tangents to this surface will be uniformly close to the horizontal tangent when I take z very small and nonetheless in the neighborhood of the origin I'm not able to say that there are two sheets which are c1 alpha right so if I take I mean if I make a turn around zero I will pass from one branch of the square root to the other branch of the square root and my surface is always connected actually whereas if I had a sheeting theorem like the one I'm hoping in the generalization of the georgies theorem I would have to have two separate sheets which are disconnected okay so and this actually has given big big headaches in the regularity theory of minimal surfaces for a lot of time but there is a fundamental theorem by Andren which is actually I mean which I cannot quote in its generality but for which I can give you at least a kind of an idea so so the theorem of Andren just says that if this quantity over here is small so let us call it boldface e so if e is small and the mass and the total area of the surface is under control so if e is small for not for a graph I mean but for a general surface so if I replace this graph of you with sigma and the volume of sigma is under control okay then up to some small errors my surface is a cover of the horizontal omega so is a say a q cover where q just gives you the number of points that I meet on top of my horizontal point at most places is a q cover and although actually I might have a singularity at the origin as it happens in this case however if I take the average of the sheets the average of the sheets is more regular than the whole object itself yes yes yes I'm taking it in the cylinder and I'm assuming and I'm assuming it has no boundary in the cylinder yes yes sorry that this is going to be a little bit vague but I mean in a few seconds we actually arrive at a new theorem which is going to have a very precise statement so I mean all of this discussion is trying to summarize things that you can actually read on surveys so for what is the reason why this theorem is important in the regularity theory and so on but then I mean in like five minutes we arrive at a precise theorem on graphs and then we will focus on that somehow and then my definitions will become precise again so and and the average of the sheets is more regular in the following sense there is an approximation so there exists an efficient and approximation which is c3 beta for some positive beta now efficient means the following so this approximation let us call it say g then efficient means that the c2 alpha norm of the derivative of g c2 alpha c2 beta sorry so not c beta like before but two derivatives more is actually bounded by a constant times the success to the power one-half and in which sense this is an efficient approximation this is an efficient approximation meaning the following in every region in every small region you look at the separation between the the two sort of sheets which are over the region and which are kind of further away and this approximation of the average sits in between okay so it's an approximation of the average meaning that at every scale the maximum separation between the sheets that you have in your object is comparable to the distance between these sheets and this average okay so under this definition you could actually go back to the original situation of the geology and ask yourself what happens if you have a single valued graph so if you have a single valued graph i'm telling you that in each region your approximation of the average of the sheets has to have distance between the two sheets which are most further away among each other which is comparable right but that's only one sheet so this the distance between the the sheets which are further away is exactly equal to zero so in the case of a single sheet your approximation has to be the single sheet everywhere and if it has to be the single sheet everywhere you actually conclude that your area minimizing graph is c3 beta okay so so let me quote this theorem by Angren and so as you see it's just a baby version of a much more general situation which is much more complicated to prove but my hope is actually to give you good ideas on how you can actually get the correct estimates in this simplified situation so if say as before u from b1 into rm has slip sheets constant less or equal than 1 and graph of u is area minimizing okay so here at the beginning i probably should have said that there exists two constants epsilon zero which depends on m and n then another constant c which depends on m and n and now the constant beta which different from alpha alpha in the georgi's theorem was any constant between zero and one so you could get you could get almost c11 estimates now beta is just some small number so these are all positive such that if you have this u which has lips is constant less or equal than one and the graph of u is area minimizing and which is the important assumption on the excess so again i write it as the volume of the graph of u minus the volume of the unit ball which was omega m so this has to be less than epsilon zero and this is your excess e okay then in the ball of rough radius the derivative of u has c2 beta estimates which are controlled by a constant times this parameter e to the power one half okay so now just i mean if you read the lecture notes you you will get a description of why somehow this theorem is important and so on so let me just give make two comments so this is just a very i mean it's a toy it's a toy problem i mean once you have c1 alpha estimates you can write down the pd for your function u and by shoulder estimates you can actually get that conclusion not only you can get that conclusion with c2 beta but you get actually that conclusion with any derivative okay so the important point is that we will prove actually this theorem without using any shoulder estimates without using any pd or any Euler Lagrange equation for your critical point in particular because the interest of such a theorem of having such a proof is that when you are in the multi-sheeted situation and you cannot write down a pd because you have an object which is not regular okay you will not be able to carry on the proof via shoulder estimates of this okay so the other comment is the following so Andren's theorem in its full generality is a step of a major work that he did back in the 80s on the regularity of oriented surfaces in co-dimension higher than one okay so it was a monograph of a thousand pages and this theorem over here i mean the bigger theorem i mean not this one which is the corollary the bigger theorem which i sketched over there as a 500 pages proof okay so i have some works with Emanuele Spadaro in which we have recast this theory in a more manageable framework and in particular we have a proof of this center manifold construction which is around 50 pages and it's much more flexible meaning that people meanwhile have picked up these constructions and they've proved other theorems whereas Andren's paper was almost unused so for us this observation that in the single-sheeted situation you can get actually C3-beta estimates without writing any shoulder and without writing any Euler Lagrange for your function U was the starting point to get this simplified proof okay and what i'm going to do is in the proof of this i'm actually following a small paper that i wrote with Emanuele Spadaro before we actually completed our program of recasting Andren's theory in a more manageable way and which in some sense it's a small self-contained work in which you you can give an idea of what are the key estimates in this central manifold construction now in the paper that i have with Emanuele Spadaro that is not the assumption that the function U that the surface is a graph okay rather than assuming that the surface is a graph i'm actually only assuming this condition over here now this condition over here when i mean since i'm taking the whole volume and i'm subtracting the volume of the disk if this one is very small it's certainly telling you that you cannot have two complete sheets on top of the other guy right so it's a weaker theorem than the one of Andren not only because i'm assuming that the surface is graphical but also because i'm assuming that this quantity is small which is right so now if i drop the graphicality assumption and that assume that this quantity is small i will not be able in a first step to say that the function is a graph but it will be a graph of a single valued function i mean the surface will be the graph of a single valued function on a very big region at least okay so the paper with Emanuele is sort of in between the general theorem and this theorem over here but it's still very very elementary compared to the to the big Andren's theorem okay so now what what is the plan of the lecture so the plan of the lecture is to give you first the proof of the georgie and then a proof of Andren in the in the way i have defined things over there okay and hopefully by the end of the second lecture tomorrow or if not by the end of the second lecture tomorrow not too deeply in the third lecture we will be finished with the georgie's theorem and then although we are not using shoulder estimates some of the conclusions of the georgie's theorem will be functional to actually prove this theorem over here okay so then therefore from now on we focus on that theorem over there no on the theorem of the georgie which i stated before and let me come to one first okay so let me say proof of the georgie's theorem so this is just the start we will do some preliminaries today and so it's i mean it will contain a lot of details but some things will be left as an exercise at least the things which are doable so first of all we are going to define this excess which is wrote down in a couple of very peculiar example in a very general situation so first of all we will define the spherical excess for a surface sigma on a ball of radius r centered at p so when i actually use this bold face ball i'm meaning a ball in the product space r m times n and with respect to a vector pi an m vector pi which is orienting a certain m plane so this excess is going to be the following quantity it's going to be one divided by omega m r to the power m so this is just the volume of the m-dimensional disc and then here i integrate over the ball of radius r centered at p intersected with sigma okay so the distance between the tangent to the surface sigma and your vector i mean your your your plane that you have fixed okay so in picture this means you just have a fixed vector a fixed plane pi a fixed m vector and you are measuring the l2 norm of the angle that you do between this pi and this tangent so here it's pi so here's your surface right and what you're doing is at each point here you're taking the tangent plane so this will be tp sigma this will look like this okay and essentially this quantity over here it tells you how big is the angle between this tangent plane and the vector and m vector pi that you have fixed oh yeah yeah yeah sorry thanks yeah this i want it to be q right and here i'm integrating in the house of measure in q thanks a lot yes so p is the center of the ball and i definitely don't want this point to be called b i want it to be called q yes thanks okay then you see that i fixed an arbitrary vector pi if i want to have an idea on the l2 oscillation of the tangents i can actually optimize on all possible pi okay and this will be called the spherical excess so if i'm not writing down here any plane then it means i'm minimizing over all possible unit k vectors okay so that's the excess on the sphere or on a ball and we will actually work often with this excess on the ball and i want to make a very important remark which is very elementary but nonetheless it's very important so the problem has a certain scaling invariance which we will often take advantage of so scaling invariance okay if i take a function u and i make the following transformation i define the new function u r and u r of y is going to be do we have it maybe over here uh no yes and you find a new function u r and this new function is one over r and then you compute u of x plus r y and you subtract u x okay so you you notice one thing the Lipschitz constant of u r stays the same as the Lipschitz constant of u right this u r is just i mean the graph of u r is just an amortity of the graph of u so if u was area minimizing then u r is also area minimizing the Lipschitz constant stays the same and this excess is scaled by this power in such a way that here in this amortity i transform balls of a certain radius into balls of a certain other radius so the excess on the corresponding balls stays the same okay so let me just summarize this discussion in the following so both the Lipschitz constant the area minimizing property and the excess are invariant under these scaling and translating so this means anytime that i will have a statement on some ball of radius r centered on point b i can actually apply this idea and get back a statement on the ball of radius one centered at zero okay and this will simply simplify a lot of computations okay and then there is another couple of elementary remarks that i want to make so another elementary remark is the following so if i so if i have a ball of radius r so if i fix an optimal plane so fix a pi such that your excess is the optimal here okay and now take a smaller ball say take a b rho q which is contained in b r p okay now i can i can simply make the following comparison so i can say the overall excess of sigma in the ball of radius rho and center that q is of course less or equal since here i'm optimizing overall planes pi then the excess with respect to that particular plane okay and now since indeed that if in the definition i have an integral right if i look at the excess in the ball of radius r centered at p which contains the ball of radius rho centered at q well the integral can only become larger but then of course i have a normalizing factor and i'm paying that normalizing factor so i can write here a very simple inequality which tells me okay this is then less or equal than r to the m divided by rho to the m and then here i will have the excess in the larger ball with respect to this plane pi but then this one is the optimal plane so of course i have this inequality okay so now with very similar arguments you can actually get other similar comparisons and let me just state a proposition here here so this is a proposition that i leave you as an exercise and it will be used very often so so u is a map from omega into rm the lipschitz constant is less or equal than 2 and you have a point p which is equal to x u of x and then another point q which is equal to y u of y okay so then there are constants c1, c2, c3 these are all geometric constants and you have the following facts so first of all you can make a lower and upper bound with respect to r to the m of the volume of the graph of u in any ball centered at p should map into rn yes and that is going to be true for every ball which is contained in the cylinder so the total volume that you have on the ball given that you have a lipschitz constant bound is controlled from above and from below by the total volume of the unit disk or of the disk of radius r okay now you can use that so you can use this first very elementary remark to actually have the following control so i can measure the distance between two planes with the excess of sigma in the ball of radius 2rp okay so that's the graph of u on b2rp with respect to pi1 plus the excess of the graph of u on b row of p with respect to pi2 and this provided i have that the ball of radius row is in between the ball of radius 2r and the ball of radius r and then of course i have to be less or equal than the distance between the point x and omega so this is simply telling you if this excess is small and this excess is small it's not possible actually that the two planes are too tilted right and then finally another very similar estimate so again for pi1 and pi2 but this time i'm actually changing the the central points so i can also say pi1 minus pi2 squared is certainly less or equal and here i will have a constant c3 and then i can put the excess of the graph on a certain ball so it's brp with respect to pi1 and then the excess of the graph of u again in the same ball with respect to pi2 sorry not in the same ball but in in in in in in this other point that i have over here and that as long as the distance between q and p is comparable so in fact we will need it in the following situation it's equal to r and of course again the distance between q and the boundary of omega yeah here's was always the boundary of omega actually yeah distance between x and the boundary of omega and the distance between y and the boundary of omega it's both time less than r okay so let me just give you a very just a very simple explanation of 30 seconds and then we finish this lecture so so what is the first estimate coming from well the first estimate is here over here is coming from the fact that the ball is contained in the respective cylinder right the ellipse constant is under control and then in the respective cylinder somehow the projection down is a disc of volume omega m r to the power m and you know over you have ellipse graph the area cannot become much larger what is what is the second bound actually coming from well the second bound is coming from the following fact so if i take a ball of reduce r here i have a central point and here i have my ellipse graph right well certainly there will be another cylinder which is slightly smaller maybe of radius b of r divided by 2 and the ellipse graph over this cylinder is entirely contained inside the ball okay and the projection of this cylinder down is going to be the disc so possibly this constant over here you can actually compute it as like 1 over 2 to the power m yes uh yeah exactly sorry and then when is this uh comparison here coming from well for instance let us take the second estimate so the second estimate i could simply say the following so take the intersection between brp and brq intersected with your graph of view by the first estimate this is certainly bigger or equal than some constant times some r to the power m okay okay and then if i average b1 minus p2 squared over here right uh i divide by this constant i will discover that this one controls pi1 minus pi2 squared and here i have 1 over a constant r to the power m okay now i with the triangle inequality i sneak in the tangent to your graph so i take pi1 minus the tangent to the graph and square it of course i do the same with pi2 and square it and then here i'm integrating on this intersection instead of integrating in the intersection i integrate once on the ball of reduce r centered at p and the other times on the ball of reduce r centered at q okay and then i get the excess with respect to pi2 and the excess with respect to pi1 well in the excess i was dividing by one over two i mean i was dividing by two here i'm dividing by some constant so then you actually get the constant that you have over here tomorrow we start over and then um go


The study investigated the biosorption of strontium-2 onto sargassum sp using a batch system. The effects of various parameters such as temperature, initial metal ion concentration, biomass treatment, biosorbent dosage, and pH were examined. The results showed that the optimum conditions for maximum biosorption were achieved when the initial pH was 7.2, the initial strontium concentration was 300 mg per litre, the biomass treatment was magnesium, the biosorbent dosage was 0.1g in 100 ml metal solution, and the temperature was 25 degrees Celsius. The biosorption capacity was found to be 103.95 mg per g under these conditions. The biosorption process followed the pseudo-second-order kinetic model and the adsorption process was described by the Langmuir and Freundlich isotherm models. This article was authored by F. Solomani, M. H. Karni, H. Palavanzad, and others.