a second to set back down for those out there in the hall to come back in. So yeah, I'm going to talk to you today a little bit about Webpack and the awesome benefit that we've had at my current company in using it. So let me tell you first of all a little bit about myself. I work at Workfront. You may have known it as AppTask. In fact, I think in the conference website it says AppTask because it was when I submitted the talk a couple months ago. There's my Twitter handle in my GitHub repository. If you want to, I've got the sample code there at the end of my presentation. You're welcome to take a look at it or now if you want. That's fine. For the last little while, I've been at Workfront. It's been all front end. Most of the time in my career I've been doing backend development. I've been doing web development for about 15 years now. And about three years ago I made the switch over to be primarily doing front end development. And the reason why I wanted to do front end development was because of the challenges and growth that we see in the JavaScript community. It seems like all the real interesting problems, the real interesting challenges to solve were in the JavaScript community. And I think part of it is because of introduction of all the different tools and platforms that we've been given over the last few years. First of all, it started out with Node.js. And of course, we have IOJS out there as well that's helping competitions good. We add our build tools to that to understand how to take dependencies in our code and build our web assets together. We add to that our testing frameworks that allow us to implement unit testing. And yes, I very much like doing unit testing in my code. So I use these tools every day. The build tools that we have to understand tasks and orchestrating various build steps to build our deployables, send them out to Heroku, concatenate our assets, and all the other wonderful things that we do. We have all these wonderful tools. And that's what makes it exciting because these tools help us to further our development and help us to build really cool applications and help us to solve more important problems and these fundamental things. And of course, we have additional supporting tools that we've had for mocking and testing and asserting and all those other things. Of course, the tool I want to talk to you about today is Webpack. Webpack, as the title says there, is a module bundler. Its job is to take all our different assets, JavaScripts, images, CSS, JSON, all the other things that you might have that comprise a front-end asset and turn them into a static bundle. One of the first things we get as a benefit of Webpack, and I'll talk about a little bit more later, is a dependency graph. It shows us the benefit of meshing our code together by expressing the relationships through dependencies. A lot of times in JavaScript, I don't know if you've seen this before. Maybe you have, raise your hand, but take a web page and you have a dozen or so JavaScript files listed there, script source equals this, script source equals that. Who's developed like that before, where you have like 10 or 12 or whatever? I used to do that as well. And what's really important about those? You have to get them in the right order, right? There's some of them that have globals defined and additional other dependencies that if you don't get them loaded in the right order, then everything falls down. You get various things. Function is not defined and various other errors that you'll get in your dev tools that try to be helpful there. So expressing dependencies can be really important. That's the first thing I want to point out with Webpack. Expressing your dependency is important with asset management, and that's not just JavaScript. We'll look at it with other assets that we use in our front-end applications. Sometimes there has to be some shaping done on those assets that we have, and so just like the wood mill here, might have to do some additional shaping to transform them into something that can be put into a JavaScript bundle. And so we'll talk about some of the loaders and things that Webpack provides. Sometimes we have to be a little bit more aggressive with the type of assets that we receive, and so maybe a wood chipper's in order. And what we get out at the end is a nice bundle, a nice tightly bundled package of JavaScript and other assets that we can deploy on a static server or CDN or somewhere else in our application. Now, you might be asking, Jeremy, there's other tools out there that do things similar to what Webpack does. Those tools are good as well. I'm not here to start any kind of war about which one's better or more magical and eats jelly beans and makes rainbows and all that sort of thing. We're here in harmony today. I just want to tell you about Webpack, the awesome things it does for us and how it can benefit you in your tool set. So let's get started by building something in Webpack and see how that might work. Let's start with something a little bit smaller. So we'll go to our editor here. I have this really awesome file, Hello World, that I want to deploy onto this web page here. You can see a reference here in this page. Not a lot in here. It's just got one reference to a script source tag, bundle.js. And can everybody see that okay? Is size okay? All right. So I have the file there. This is entry.js and I want to go ahead and deploy it as index.html. Let's widen this out here. So I'm going to run one command Webpack, entry.js. And we want to output that as bundle.js. So it did some work. It generated a file called bundle.js. And if we open that file in our browser, we'll look at that amazing. We have Hello World on our page, index.html. You might be really amazed here, but really all we've done at this point or proven that Webpack can do for us is something as simple as this other command, or we can copy files. Great. We've got this glorified file copier. There's nothing more for us to learn here from Webpack. Maybe for all you guys know, I just aliased copy to Webpack and just for this talk. Well, there's a little bit more we can do here. So let's create an additional file. I was talking about dependency graphs and dependency charts a moment ago. So let's create a new file called content. We'll bring that up in here. So this is our blank file. Let's just say for entry here, let's get rid of the index.html. We don't need that right now. Let's take right here. Oh, we want this text right here to be customizable on its own dependency. So we'll just move that out into its own file. And we'll replace this. Notice I'm using module.exports, common js syntax. Just brings that constant or rather string literal of hello world out. Add to my entry. We're going to require that file in. These files are both in the same directory. We'll bring it in. Again, common js syntax. Let's run Webpack one more time. And you can see it's worked with two files here at this point. If I reload my browser, I've got an extra mark there somewhere, but it also says hello world. So I think I added that to my index.html. Look at that little tick mark. All right. So we've proven right now that we can load a file in. If we actually open the bundle down here below, you can see the exports and the various things that we did here. But you see all this Webpack stuff around it. It's actually fairly human readable, even though it does a lot of extra stuff for your file, at least in this mode. Let's do something a little bit more. But for me, it's a little tedious typing Webpack over and over again. So we'll just get a watcher going on this with the same files. What that's going to do is it's going to listen to files. Anything that's an entry file, like our entry.js is going to listen to that file along with any of its dependencies. And when those files change, it will go ahead and run the bundler again and put that together. So this should make things a little bit better. And in fact, let's try something like change this to Mountain West.js. Save. You'll see that the bundler just kicked off there. If we go to our browser here, we can see the change there. Nothing too earth-shattering at this point. But there's more here that we can do. We can also bring in dependencies from other third-party libraries. So I happen to have a library here that requires moment.js. It's called display time. Just say we want to add the current date and time to this page just for the purposes of our demo here. This is the file I want to use. One thing to note here in this file is I'm using AMD syntax in this file. Webpack by default understands common JS syntax as well as AMD. So you can take some of the existing AMD modules that you have. Like at work front, we have a lot of required JS that we've used, and so we have a lot of AMD syntax or files that are annotated with AMD. We can go ahead and take files like that and bring them into the system and Webpack understands them natively. Not only that, but it understands third-party dependencies over here in my project in the node modules. It's a little bit smaller than the rest of it. I have moment loaded as an MPM node package dependency. And so it's going to go ahead and look at my node modules to grab that file, that resource, bring it in, and that's going to do the action that's in this file. For us, we don't care whether it's in AMD syntax or common JS, we can bring it in the same way we bring anything else in. So if I wanted to add here, the current time is, and just require that file, can add that to the end. We'll see additional action happened here. It picked up the display time because, again, that's part of the dependency graph now. And it compiled that file. Let's go back to our web browser, refresh, and we can see our message here. And along with the current time with some poor spacing there that I did when I edited that. So let's fix that because that's a little OCD. That's going to bug me. All right. There's another thing that we can do with this is as you get more and more resources, you're going to want to open your DevTools and you're going to want to either use the debugger or you're going to want to go through and see where how things are working. Well, you can see here in the source, this is my bundle.js that it created. It's human readable, but it's not really something that I would want to look through and step through with the debugger and try to figure out which file has a mistake in it. And it makes it difficult for me to reason about. So we can add, there's source maps built into Webpack. So I can go ahead and take the line we ran before. There's a variety of ways to do this and a variety of configurations that Webpack supports, but I'm just going to use the default source map one. So we're running that. So a watcher is running, it's listening, notifying us of changes and building by the bundler. It's also generating a source map. So if I go back now and reload, yes we get our bundle here, but you'll see this little Webpack namespace down here below and expanding that out just following our same directory path. We can see our entry file that we had, our display time, and our content as well. And not only that, but we can add here to our display time. Let's just say we wanted to step through when it's going, we're having an issue formatting the time or something. We want to take a look at that. We can just add a debugger statement there. It rebuilt again, reload, and it hits the debugger, and you can see the location here. It's hitting the breakpoint that we just added into our code, the debugger statement. So it's very flexible to just want you to start getting, get going with some of those features. I mentioned earlier with our dependency graph, our web applications aren't normally just comprised of JavaScript. They're also comprised of CSS and other assets, JSON, images and whatnot. So let's add a little bit of JavaScript to this because white and black is kind of plain. So in this page we want to, let's just first of all create a new file here, collapse that, new file. We'll just give it a really awesome name like style.js, and, or style CSS, and we'll just style the body, let's say a font size, we'll double the font size because it's kind of small and we'll give it a background color of, I don't know, green, yellow. Now you'll notice that nothing changed here because we haven't added it to the dependency graph yet. So by simply requiring right here the file, let's start with that because that's how we've added things to the dependency graph up to this point. So add that to the top and run and it says, oh unexpected token, you need an appropriate loader to handle this file type. So of course it doesn't natively know how to handle CSS. We have to give it some things that will help it understand how to take CSS and embed it into our JavaScript assets. The way that this is done within Webpack is through the use of loaders. Loaders usually take some kind of input and they can transform them into another form here. We're actually going to leverage two loaders here. The CSS loader, I've already loaded them because I didn't know how the network access would be in here, but we're using the style loader and the CSS loader. The first, these actually read right to left, so you go back through it backwards. So it's going to run the CSS loader on it which knows how to read the CSS and bring it in as a JavaScript asset and then the style one here knows how to actually apply it to the screen. It says, hey apply the CSS to the page. So let's go ahead and add those transforms in there and you can see it's a building again. Let's see what it does to our page. Reload, it doubled our size there and added the background. This isn't very common JS style right here, adding these additional loaders. So another thing that we can do is we can put this into a configuration file where those transformers, those loaders can be added. So let's add ourselves a webpack configuration file. The default file name is webpack.config.js. And this is just regular JavaScript file. And what we can give it in here, we can give it a variety of things that we've been doing on the command line. We can give it the entry point and we can actually have more than one entry point which we'll look at momentarily. And we can give it the output. So let's just add those right from the outset here. Make sure that those are all working. And that's a minimal file. What that does there is that allows us to omit the config or mentioning the entry and the output file name on the command line and just it'll get them from the config file. So we just type webpack with our commands here. You'll notice here I'm using a dash D. That's for dev mode. What that'll actually do is do the source map, a shortcut for doing a source map as well as some of the other things you do during development mode. So I'm doing a watcher and a D here. We'll put that in. It's running the build and we can reload and it's still working. Let's just double check that it picked up my changes. That needs to be an exclamation point. So we'll change that and reload and we've got our exclamation point. So the thing, the reason why we added the configuration file in the first place is we wanted to actually move the loader functionality into a configuration rather than inlining it and our requires. The way that we can do that is through adding the loader to our configuration file. In the module section there's a thing called loaders. And what this is is we supply some rules here that tell webpack how to configure, how to work with various assets. The first thing we start with is a test and this tells it, it's usually a regex that tells it what type of file should have this loader applied to it. We're going to say anything ending in CSS. We want the loader and we can actually just take the exact same syntax we did on the other one and add that style of CSS there. Because we've made that change we can remove that from our file here and let's, we need to reload our webpack just because we changed the configuration. So let's start that up again. And the change is working. One of the things that maybe you haven't noticed but it's kind of tedious for me is I'm having to go through and refresh the browser every time I make one of these changes. Wouldn't it be nice if I could actually have it also refresh the browser when I make one of these changes? So what we're going to add here is a webpack provides a webpack, it's called webpack dev server. Let's just make sure that that works. I'm going to add some additional configuration here. This inline flag just adds it, it adds a socket IO library to the web page, embeds it in there that will actually listen for changes and knows when to reload assets on the page. That coupled with hot is our hot reloading. So we'll just add those to the page. There's some other things that we can add here which tells us our file progress and we all like colors. So we'll add that here. So it's serving up, you can see it's actually processing a number of files not just our entry files. It's also processing all the locales in the moment dependency we added. We'll talk about that more later. So we got our library here. We need to switch this to actually it'll by default it serves up on port 8080. So it's got that page here. Now as we make changes which the most the easiest one to show changes is to just show the CSS. It's going to go ahead and pick up our changes as we do that. And it also does that with any of our changes we make in here if we want to change the format of the time it's going to pick up that change and bring it in. That's kind of a brief introduction to what you can do with Webpack and kind of get in a basic development environment setup. That's actually about 80% of what you would do with Webpack. It's just describing your dependency graph, the various assets you want to bring in and applying the appropriate loaders to to make things work. But we can go a bit further with it and I want to show you a few other things that we can do, some tips and tricks that will help your Webpack experience go better. So let's see. So sometimes right just make sure I've got everything in a good place here. Clear some of this cruft out. Okay so we actually have a new project in here. You can see our Webpack configuration has changed quite a bit. As I mentioned earlier you can have multiple entry points. Many of us have multiple pages in there. Even though we develop a lot of single page applications there might be multiple sections within that application and so we want to maybe represent those as as separate smaller single page applications. This one here I have a grocery entry and a to-do entry. You can see the output here. We're just using one of the metadata variables that Webpack has called names. It'll just take whatever this key is on the entry and it will use that as the name of the output. I've given a little shortcut saying I always want source maps. So just generate those as part of my asset and I've added some additional loaders here. One in particular that's really useful now with ES2015 out there is is the Babel loader formerly 6-5 which allows us to transform our assets. We can write them in ES6, ES2015 and have them transformed into ES5 where we can actually consume them in most of the browsers out there which is really really cool. So let's see how that works. I'm going to get my Webpack Dev server running again here. In most of these command line settings actually nearly all of them can be put into a configuration. There's just some of them I prefer not to have in my configuration file because I'm also using the same file for producing production output. So let me just put those in here. Okay so we'll take a look at what this looks like. This particular app is pretty, is not very interesting. I've just got two pages, groceries where we can enter our groceries. Not too interesting and it has a to-dos page where we can, you know, model on, take a nap. I think that should be a task. Anyway, so you can add to-dos and you can check things off and it understands how to do that. Let's look at the code and see how that's set up. So here let's start the to-do entry. One thing you'll note here, we're using ES2015 all the way through. We're able to use the import here. By using the Babel loader it's able to understand that kind of syntax. So we're not constrained just by using, you know, the common JS syntax or the AMD syntax. We can also add this to our pages and of course we can use the other one as well. It just understands all three variations which is really nice. Here we're just creating, we're just importing that class in and creating it and attaching it to the body. It understands all of ES6 syntax or at least what Babel understands at this point. So we can bring all our dependencies in this way. We can use inheritance. All the nice things that you would want to be able to add with your ES6 stuff. One of the things that you'll note that I want to show with these change- oh the other thing I wanted to show with this is the to-do app is inheriting list app which levers the list model as well. That's where we're storing the code and really the only thing that's different between to-do app and grocery app is this root template. One of them says your to-dos for today using moment to format it and the grocery app that I showed before just has a different template that says your grocery app. That's really the only difference is that kind of that frame around the entire application. The list management, how they're stored, is all identical and it gets that through the inheritance here. Which means when we're loading a page here, let's look at some of these. Close that down here. So you start seeing some of these sizes. To-do app.js is 563k. It's pretty big. What do you think's the reason why that's so big? It's moment. Moment has all those locales that was loading in before. It's adding a huge demand to our thing. This is one of the downsides when we start looking at some of these tools like browserify and webpack is we got to be careful when we bring in third-party dependencies from node modules that we're not bringing in a lot more than we wanted to bring in in the first place. One of the ways that we can fix that, I'll show you in a minute, if we look at the groceries one, it's still fairly small here. It's 146, which is still kind of big for just the basic grocery app but it doesn't have the moment constraints. So let's take care of the moment one first and then see what else we can do. The first thing we can do is in our configuration, this is by default going to bundle everything that you described. It's going to traverse down that dependency graph and it's going to incorporate every asset that it finds and bundle it in. But we can give it some hints to say don't bundle certain things. So I'm going to tell it when it comes across moment and there's a variety of ways to do externals here. There's a map syntax and some other ways. There's ways to say, hey, when I get this variable in, it's on window.jquery, for instance. This is saying when I come across moment, window.moment is where I can access it. So in order to fix that so that we can actually get moment that way, I'm just going to add that script here. I think it's that one. I hope I get the right one on the first try. So it's serving. Let's take a look and see if the to-dos one, whoops, to-dos. It's always that plural. So it's getting the date in and let's see. So it's loading moment in and you can see our to-do app is much smaller. It's actually comparable in size right now to the grocery app. So we're able to reduce that. One of the things we want to think of is if we're hosting some of our third party modules, if you're using something like jQuery, if you're using something like moment or low-dash, things that are common, you may want to consider for performance actually hosting them separately, particularly if they're on a CDN. Leverage the user's browser cache or if you're using basket where you're storing them a local storage or something like that. There's a variety of options. The point is that we just changed a little bit of configuration and we were able to fine-tune our application to make some of those bundle sizes smaller. One more optimization we're going to do before I get off the stage is we can take advantage of some of the shared code options here. Now, as I mentioned earlier, to-do app and grocery app pretty much have the same code base apart from one little thing and that's their individual classes. If we require a webpack in and we use one of the plugins, there's plugins that webpack provides as well as far as how to configure our dependencies, how to optimize them. And one of them it provides is the called the commons chunk plug-in. What that will do is it'll look at the dependency graph, find commonalities between your various entry points and optimize those into a single file. So we'll do that. Optimize commons chunk plug-in and we give it the destination. We'll just call it init.js and then we just load a plugin section down here. Let's see here commons chunk plug-in. That should work. Let's see. You can see it's creating an init.js and you can actually see the size here that it created. These are very tiny now. The init.js is much larger than the other ones. Now, of course, in order to use those on the page, webpack is a module bundler. It's not a module server. So these are going to break because it can't find various things. You have to add the dependency to the page. Now, you can do this a variety of ways. There's tools out there like script.js, head.js, just script tags like this. You can actually use, you can package your stuff as AMD modules and you can use require.js on your page to host your files. There's a variety of ways to actually package these things. Let me fix that last one here. When we load that page, you can see the to-do stuff's coming up again. You can see this additional init added here that has the bulk of the code and the to-do app is very, very small. So if we had a lot of shared code, this something like the commas chunk plug-in can really help us out because as they visit one page, they're going to load that into a browser cache. They go to the other one. It'll be able to use a lot of the same assets. So there's a lot of benefits here. That comes from us using whether you use require.js, webpack, browserify, any of those out there by being able to define our dependencies, instead of defining them as globals, defining them in this nice dependency graph. All right. So other cool features that I obviously don't have time to present right now. They have image inlining. So one of the things that we've used is, I don't know about you, but we've used a lot of like sprite sheets and things. One of the things you can do here is by using the CSS plug-in with the image loader plug-in, you can actually inline your images using data URIs instead. If they're very small, you can get those in your CSS so they can be baked into the whole asset. There's feature flags where you can have kind of dev mode things. If you want to, like my to-do list, I could have used the, had some JSON staging the to-do list with some sample data. Well, it's in dev mode. Well, during production, I don't want to present it that way. The library output is really cool. Like I mentioned earlier, you could use require.js on the page to host it. You can output these using common.js, UMD, AMD, just a variable on the page. And if the, there's a variety of different ways you can actually configure the output to be generated on the page, so you can run it in a variety of configurations. At our work right now, we use AM, we've been using require.js on a lot of stuff. So as I'm building these node packages outside the main application of feeding them in, I build them in, with the AMD configuration and that way they can be bootstrapped in the application, even though I'm building them using Webpack. And finally, the testing story is really good with Webpack. There's a karma loader out there and pre-processor that we use. We've got Istanbul bootstrapped into it and so we get coverage, tests, all that stuff. Imagine the Webpack Dev server cycle that we've been doing here where it's kind of, as we make changes, we see them reflecting the browser. Imagine the same thing with your tests and you're instantly getting coverage, linting, those other things as well. It's a really nice development process. I really enjoyed it a lot. Just a couple of resources. There's the Webpack homepage, of course, Webpack.github.io. There's my repository that has some various tags in there that show the sample code that I showed here. This document by Pete Hunt is really, really good. I'm just showing how to use Webpack in a variety of ways. He covers some of these features as well and how they use it in practice at Instagram. So anyway, thank you for your time. Thank you for having me at Mount West JS. I've been told I have time for two questions. Right. Okay, so the question was, with externals, are you able to minify those? It depends on how you set them up. So one of the ways I showed there was to take the moment and just assume that it's a third party library and host it separately. The other way that you could do it, do that exact same thing is what I showed with the commas chunk plugin. You could actually build a separate chunk that has just your third party libraries in it, like a vendor module, if you will. And then those could go through the optimization and minification that if you wanted to host them that way. There's a variety of options. But with externals, it basically says something else is handling that. This is just how when I get a require this, I'm going to know where to find it. All right. I think everybody's ready to go. So I think another half an hour, right? All right. Thanks.


Thank you. I want to take the opportunity to congratulate organizers in particular Carlos because it's been a great conference and thank you everyone for being here. So now I'm going to talk about this project about estimating the human development index at very high resolution using satellite images. This is a project that we are doing with colleagues from different centers but this is mostly around the global policy lab in UC Berkeley. So probably all of you are familiar with the human development index but I think it's important to remind you about what this is about where it's a multidimensional indicator of capabilities. It captures the health measures using life expectancy at birth. It captures education measuring the expected years of schooling that is associated with achievements from kids up also mean years of schooling reflecting the education level of adults and also a decent standard of living which is captured using the GNI per capita. So I'm not going to go into the definition but you just need to get the general idea and this is probably the main indicator to assess multidimensional development that we have is very popular and it was a sign to measure things at the country level. Now we release every year the country estimates and I have to stress that this is a very political thing. We are part of the UN and this index is used to eventually rank countries that are the member state, these are our bosses. So the reason why we are allowed to do that is because there is a general assembly resolution that gives us the mandate or the possibility of doing some independent research but we need to follow some certain rules and one of the main rules is that this has to be based on solid evidence and here the issue of comparability becomes very important. So it's very hard to have good data that is comparable across country. So this means that in general we have faced many years restrictions in order to advance towards to more designery level of data. There are many experiences of countries that they have the freedom to develop their own human development index but we don't have a comprehensive measure across country. Except for recently this paper by Iñaki Permanja and Smith and they but this is an independent project of researchers that were able to develop estimates of human development index at the province level for the entire world. So the question that we try to answer is whether we can use satellite images to make predictions about development indicators in a consistent way. Why this becomes important for us? First because now we have a lot of new information that is available that we can use and there is a lot of evidence that this can be done. And second and this is important for our purposes is that this data follows certain standards. So it gives us the opportunity to measure things in a way that cannot be questioned and also that will allow us to make progress in tracking what is happening with development at a very granular level. So this is a very broad agenda but here I'm going to concentrate only on the emphasis on the HDI and I have to emphasize that this is experimental and so far we are not sharing the data but I think it's just to open a conversation. This is not official and we can do many things and we are going to be talking today about downscaling. So what is downscaling is that eventually we have data at the country level and how we go from that to provincial level and how we go to that to municipal level. So just to give you an idea of how this works we have 193 member states but typically we publish information at least for this project we have data for 189 countries. In terms of provinces we are working with 1,700 units and if we go to municipalities we can eventually cover more than 60,000 units. So the methodology I will try to make things simple because actually the methodology is not very complicated. It takes in a very flexible way satellite data using daytime images. We also complement this with something that has been tried before quite a bit which is nighttime lights but the main innovation is here and what happens is that we have images that through a process that is based on some algorithms of random convolutional features that captures some of the principles of convolutional neural networks but in a much simpler way. So we transform an image in a vector of numbers. We don't know the meaning of those numbers but it's just a vector of 4,000 numbers for each image. So then we have information nested there and then we use that information in order to understand something. In this case the human development index that if for a certain area we have a value of the human development index we can train the model to understand what of the features that are coming from here are relevant to predict the human development index and we find the coefficients. In order to do that we cannot use a very simple or less regression which allows us to reduce in practice allows us to reduce the number of active coefficients. So now the results. So here it's going, this is an exercise that goes from province level to province level. So I mentioned that there is this paper by Permanger and Smith's that computes HDI at the level of provinces. So in this exercise what we do is to try to take some part of the sample like 80% and we run these regressions we learn and then we test this with the rest of the observations. And these are the results. So the feed is very good and the area square is 78%. So this gives us an idea of the potential for instance what happens if we have information for certain areas of the planet and not for the others so we can use that information that we have to learn how to identify levels of human development index and then predict that over the other areas. Now this exercise is about on scaling. So here is what happens if we have information only at the country level and we want to now try to find information at the province level. We can test this because we have the data from Permanger and Smith. So here what we do is first run a model that is a model in differences that captures the within country differences of the different provinces and then using the country level we recover the final number and the results are very impressive. So you can see so these are the final results and we have that the feed is excellent with an R square of 96%. So this is very good news because it tells us that eventually even if we don't have very segregated level and we just have aggregated level national level data and we have access to these numbers from satellites we can get pretty accurate predictions at this level, at the state level or province level which covers like 1700 areas in the plan. Now this is the result of this exercise. So in a way it's not very different from what we can find in the Permanger and Smith's paper but the interesting thing is that we were able to generate it just using country level data with satellite images. Now do you have a little water? No, water. No, I'm sorry. I have one mouth. So now but the question is can we move to the next level? From province level to municipality level the problem we have is that we don't have information of the HDI at the province level that we can use in order to actually test the validity of the exercise. However we have other variables for which we can identify the values at the municipal level. Now one of them is night light because precisely this is something that has been used as a proxy of development and we can see that if we do this exercise jumping from province level to municipal level the fit is very good and it's 78%. So it's not as good as in the other case but it is still very good. We also have information about the international well index sorry this is coming from mostly from DHS surveys and also we can using the same procedure find a very good fit with an R square of 0.75 which is again not as good as the 96% we found before but very good. So based on this we're encouraged to go to the next level using the human development index and this is what we find. So these are estimates of the human development index that jump from the province level to the municipal level using satellite data and these are over 60,000 small areas. So I think we're sorry very encouraged for these results now let's try to connect this with the so why we are doing this well it's going to be very important in order to improve policymaking so this is just an exercise of what we are gaining by doing this exercise here we have quintiles based on municipal level HDI and here we have the bars reflecting the previous classification the quintiles just taking into account provinces and we can see how we can uncover things that are hidden if we just use the province level exercise for instance here we have that 17% of the population are labeled using province level information in the 13th tile what in fact they are part of the top of the distribution and of course we can improve targeting in the other part of the distribution but the most important thing for us is that is the space that this research opens in order to understand what is happening in the world today and what is expected to happen tomorrow so many of the problems we are facing as part of the Anthropocene context are very difficult are very complex and we are trying to find information that can give us indication of what is going to happen because of climate change on human development in different parts of the world so we are going to be launching in the next few weeks a platform that is going to be giving us this information information about mortality information about what is going to happen to workers probably next year we are going to release information about what is happening with agriculture coming from climate change and all of this information is going to come in a very granular way so I think we are going to need some tools in order to make sense of this information and use it and cross this information with other variables so we think that in order to do that to go to the next level in this type of analysis it is critical that we can desegregate variables that we know are important in the analysis one of them is the human development index but I think for us this is just the start so I'm going to close with the conclusion so what we have shown is that there are promising results desegregating development variables in this case the human development index first it is possible to do this in a horizontal way province to province also it is in our view very promising the ability to have to downscale variables from natural level data which is what we have which is more common to the next level that is province level data and also we see that there is a very interesting space to go to the next level we are still doing more research on this to get that with validation but I think we are on track on that as I mentioned now we are trying to push this agenda to include more variables also to to have more clarity how we can validate to understand what works what doesn't work and also we are working in making these resources more accessible to researchers because I think this is very powerful and it would be important that can be used by in different parts of the world so hopefully we are going to be able to construct some platforms so things like that that would make this easy for other researchers to use and of course this is very important for a better formulation of policies and also for pushing the next generation of research so I'm going to stop here, thank you


Let me write down what is the problem. So again to do this, there are certain rules. So these rules were derived by John C. Slater and they are usually known as Slater rules, Slater rules for matrix elements. In fact, these rules should be required even when I do C i because remember when I do C i, this I have to calculate matrix element of the Hamiltonian in terms of the d i d j which are like determinants. So I must know how to write the matrix element of the Hamiltonian between two determinants. So that is the essential problem in terms of the spin orbitals which form the determinants. So first rule A is the expectation value. In the matrix element, one important point is expectation value which means both sides are identical. Left and the right is identical. Again I am assuming that they are all orthonormal set. So all the rules are derived using orthonormal set. So psi tilde is chi 1 tilde, chi 2 tilde, chi n tilde while chi i tilde, chi j tilde equal to delta i. So that is the problem. So the rule is that if I can expand psi tilde in terms of chi, I can expand psi tilde in terms of chi on both left and the right. I can write h as sum over h of i plus 1 by sum over 1 by r i j and then do lots of integrations. Now it is very complicated because you have n factorial, you have one term here but this one term is actually determinant. So there are n factorial terms, chi 1, chi 2, chi n, then chi 1, 1, chi 2, 2 is interchange, etc., etc. n factorial term with a 1 by square root n factorial on each side. So 1 by n factorial. So if you see, it may look horrendous but actual analysis will tell that this is very easy and this is what John Slater did. What I would do is to simply write down the results. So let me write the result first. First let me write down h again because the symbols must be correct, sum over h of i plus 1 by r i j. So this goes over n electrons, this also goes over n electrons. h of i is a kinetic plus electron, whatever external potential, electron nuclear attraction or any other external potential. This is my total Hamiltonian. Remember total Hamiltonian has only a sum of one electron term and sum of two electron terms. There is no three electron, four electron term because this is a Coulomb interaction. So that is the hallmark of Coulomb interactions. I have two parts to this Hamiltonian, this and this. Let me call this a 0.1 within a. So a 0.1 is just the psi tilde sum over h of i psi tilde. So the first part I am doing. Remember this is sum over h of i. So there are n terms here. So how many terms are there which have to integrate? There are n terms here, n factorial here, n factorial here and of course everything will be divided by 1 by n factorial. So it looks like a horrendous number of terms. But remember when I am doing this, let us say I do two electron. So I have got chi 1 tilde 1, chi 2 tilde 2. Let us assume that everything is real. It does not matter. We can write star. So one of the terms, then chi 1 tilde 2, chi 2 tilde 1.  So this is what it is. So please do this. You should try to do this at least two electron problem manually because there are not that many terms. You can expand each of the terms. So what is the first term? Let me expand. So chi 1 tilde 1, chi 2 tilde 2, let me write in Dirac notation. Actually if I write in Dirac notation, I do not need to write the stars. I can knock this off. Chi 2 tilde 2, h of 1, chi 1 tilde 1, chi 2 tilde 2. So that is the first term. How many terms are there? 2 into 2, 4 into 2, 8 because h 1 plus h 2. There are 8 terms actually. I am writing only one term right now. There has to be h of 2 here. I have to do the integration. Integration is over d tau 1, d tau 2. Now you can see it is a trivial integration because h of 1 can only connect one pair of spin orbital. The rest can be directly integrated. So these two can be directly integrated and that gives you 1. So what is the result of this? The result of this is just chi 1 tilde h chi 1 tilde. Is it clear? Just a simple one electron. Now it does not matter if there are n electrons here. n spin orbitals in here, they would all have given you 1. 1 into 1 into 1. Let us take another term where this is h 2. This is h 2. So let us take the same term where this is h 2. You should be able to do these integrations. Now in this case, you will get this as chi 2 tilde h chi 2 tilde. Instead of chi 1 tilde, because chi 1 tilde, chi 1 tilde will become 1. So you have a chi 2 tilde h. Now this was a coordinate 2. This was coordinate 1 which survived but that does not matter. I am going to integrate. So it is a dummy variable at the end of the day. The integral result will be identical. So this is a number which will be over chi 1 tilde. This is a number which will be over chi 2 tilde for each one of them. Now if I interchange, it is very easy to see. If I interchange only on one side, chi 2 tilde 1, chi 1 tilde 1, what will happen? This will become 0 because now h 1 will connect chi 1 here, chi 2 here. 2 which is not connected will be chi 2 here and chi 1 here and they will become orthogonal. In fact, all such interchanges will become 0. So the only thing that will survive is whatever you have written here from these four terms must be the same as here. So one more will survive. When the left is this, right is also this. So that will survive of course and h 1, h 2 will be there. For both of them, four terms will be there. So you will actually divide by 2. 1 by 2 is already there. So you will actually get only two terms. Your final result will be just this. The final result is chi 1 h chi 1 plus chi 2 h chi 2. That is all. You have already got one chi 1, sorry chi 1 tilde h chi 1. You have already got this two already got this, but with a factor 1 by 2. Do not forget. You will do it once more. You will get the same thing. Negative and negative sign will give you positive. You will exactly get this twice. Cancel with 1 by 2. You will get them twice. You will get them just once. So this will be the final result actually. So for two electron, you can see the rest of the terms are all vanishing because of the orthonormality. The orthonormality is a very, very important part. This condition is very, very important. Otherwise, of course, the rule should be very, very complicated. See if I do this, I can now write the general rule. So I just showed this for a two electron problem. So now I can write a general n electron problem. So a point 1. So the general problem is chi tilde sum over h of i, chi tilde is equal to sum over i chi i tilde h chi i tilde. It is very easy to generalize. i equal to 1 to n. Just as you have got this for two electron. So it is chi i, h chi i, i equal to 1, i equal to 2. So I write exactly in the same manner. For n electron, you will get n matrix elements. Now you can see the entire problem at least for the first one when this is just this has become very, very simplified. It just has sum over n 1 electron matrix which is very easy to calculate and now it is directly in terms of chi. Now this is of course not surprising because this was non-interacting and in non-interacting, we know that the energy is just sum of the one electron. So that is what you have actually got. So it is more interesting to look at what will be the second one, a point 2 which is chi tilde 1 by r i j chi tilde. You can actually try doing this for two electron. In fact, I will give you this as an exercise to try this for two electron. I will write down the final result, but please check that you get this for a two electron problem in the same way that I have done. This is half of sum over i j chi i tilde chi j tilde 1 by r 1 2 chi i tilde chi j tilde. These tildes are just cosmetic. Do not worry about it because I am using trial functions or I am using tilde. It is not important. Minus chi i tilde chi j tilde 1 by r 1 2 chi i j tilde chi i tilde. That is an exchange term.  So within coordinate 1 and coordinate 2, I can interchange they will not become 0 because the orthonormality does not work here. I cannot integrate these two separately, but all others get integrated either to 1 or to 0. So if the others are there, they will not interchange. So they will become all 1. If they interchange, they will become 0 and this number comes out correctly because of again this 1 by n factorial. That you can check. You have n c 2 term here. You have n factorial here, n factorial here. You can check this for two electron problem 1 by r 1 2. There is only one term here. So here, this is a very important result which I am going to use and the result says there are two terms. This term is called the Coulomb term where one of the electron is in spin orbital chi i. Another electron is in the spin orbital chi j. Remember again, I am always using the Dirac notation. I think I have first said that 1 2 1 2 notation. So it is star 1 star 2 1 2. So I have a density of chi i spin orbital interacting with the density of the chi j spin orbital through 1 by r 1 2. That is a classical Coulomb interaction of two particles. And of course, if it is n particle problem, so all the others are coming through this sum over i j. The dummy variables remain 1 and 2, but the spin orbitals keep changing because spin orbitals are important. This one I cannot interpret in the same way, but this is quite obviously it is a Coulomb exchange interaction which is basically interchanging the left and the right side. So this two electron part boils down to Coulomb and the exchange part. Note that this sum over i and j spans entire 1 to n, i equal to 1 to n, j equal to 1 to n. It is quite easy to see, however, that whenever i is equal to j, note that this Coulomb term and the exchange term become identical because i is equal to j. So the interchange does not produce anything. So for all i equal to j, each of the terms is not 0, but the negative, the entire thing is 0. So actually in this summation, so let me refine the a 0.2. In this summation, I need not write the i equal to j part. So let me write this. So a 0.2 then becomes sum over i not equal to j half chi i chi j 1 by r 1 to chi i chi j minus chi i chi j 1 by r 1 to chi j chi i. You can further see by symmetry, if I interchange i j that is i to j j to i, each of the terms remains the same because it all means just coordinates are integrated in change. This is a dummy variable. So both of them would be identical which means within i not equal to j, i less than j and i greater than j are same. So the entire thing can now be written as just one of them i less than j chi i chi j no not equal i less than j and the same term. And now because I am taking only i less than j, I do not need to take the factor half because I have divided this as i less than j plus i greater than j. Both of them are identical. So without if you do not write the factor half, just write this and this will give you the physics that I am now the two electrons are interacting and pairs. i less than j is basically two pairs of spin orbitals which are different. Of course they cannot be same because of Pauli principle. So they have to be different and those two pairs of spin orbitals only interact. So if I have a chi 1 and chi 2 interaction is only once between chi 1 and chi 2. This was giving actually a somewhat superfluous result that I am interacting chi 1 and chi 2 twice. Even if i equal to j is ruled out, when i equal to 1, j equal to 2, i equal to 2, j equal to 1 each time I am counting and totally unnecessary because the factor is half they are identical. So that now this gives you the chemistry that this is a pair wise interaction coulomb and exchange. So pair wise is actually defined. So these notations of symbols are very important. So when you write these please remember your factor will depend on how you write. All i all j, i less than j both are identical i equal to j is a 0. So you do not have to worry. So coulomb and exchange. So this is what is called that the self interaction cancels. In fact this is later will be used in DFT and several other theories. This is self interaction that i and j they do not interact with each other. The coulomb and the exchange term cancels due to this anti-symmetry. So i will leave you here. I have to of course come back to the then i am now going to put together a 1 and a 2. So i will get the full expectation value and then of course i will also look at the matrix elements where these and these are different which will be required later. So probably i will not do it now when it comes down i will come back to those rules. So they can be different also they really become matrix elements. What i am looking at here is a special class of matrix elements which are called expectation value. Expectation value is essentially both left and right are identical. So that is what i am looking at right now. And that is sufficient for the Hartree form.  I have given you a 1 and a 2. I am going to put them together. These are the coordinates of the electron is 1 and 2. This is the coordinate of the electron. Chi i and Chi j are spin orbitals. The sum is not over the coordinates. I again repeat. The sum is over the spin orbitals. The coordinates are always 1 and 2. You can choose 2 and 3. You can choose 1 and 4. It does not matter because these are dummy variables. So you may wonder where are the n electrons coming? Why only 2 electrons? n electrons are coming because of this. Either you sum over electrons or you sum over spin orbitals identical. So they are indeed 1 and 2. So I want to make sure. That is a good question. So when I am writing this as Rij, this is meaning because this is a total Hamiltonian. So I have 1 by R12, 1 by R23, 1 by R13. Everything is there. But eventually when I come to matrix element, you can write everything in terms of a specific 2 electrons but sum over all spin orbitals. In fact, this is very important that you said this question because many people get confused with the indices and this sum is actually making sure that you are taking over all pairs of coordinates. That is why I said there is a factor 1 by a n. All that will cancel out just like it happened for. For example, if you look at my 1 electron problem, there are also I did not write this is 1, this is 2.  Both are 1. Both are 2. It does not matter what it is. 1 can be 1 and n can be 3. That electron coordinate does not matter at the end of it because that is what is being integrated. Please understand. All integrations are definite integral. I again repeat. So all of you know in calculus, if I have definite integral, the coordinate of integration just vanishes. So it does not matter whether what is important is the level of the spin orbitals. They are different chi 1 tilde and chi 2 tilde. Is it clear? So what I am saying is the same question you could have asked here. This is not 1 and this is not 2. I mean this can be 2. I have no problem but both can have coordinate 1. Fortunately, this is 2 electrons. I wrote all the things. Here also I can write similarly for 2 electrons. You do this as your own practice so that you are able to derive this for 2 electrons where this 2 electron part is just 1 by r1 and chi tilde is just chi 1 tilde, chi 2 tilde. So it is very simple. You write down like this, expand, put this factor and derive.