So I guess we'll get started right now. Thanks everyone for closing out CF Summit with us. My name is Angela Chin. I'm a software engineer at Pivotal. And I'm Christian Ng, another software engineer at Pivotal. And today we'll be talking about deploying Cloud Boundary using the newest set of open source tools, Bosch Bootloader, or Bubble for short, Bosch 2.0, and CF deployment. So before we delve into the meat of the talk, we just want to take a quick temperature of the room to see where everybody was at. So who here has used Bosch Bootloader before? Hey, awesome. How many of you have used Bosch before? Cool. How about use the new set of features in Bosch 2.0? How about deploy CF using CF release? How about CF deployment? OK. So it seems like we have a good variety in this audience about all of these sets of tools. But we're really hoping by the end of the talk that everybody is sort of level set on how to use all of these tools and what the power of using all these tools is and is able to go out there and deploy open source Cloud Foundry on your own. Cool. So to kind of start us off, I want to describe what does it mean to deploy Cloud Foundry? What does it take? So as you can see, this is a very complex diagram, which you don't have to dig too deeply into it. But it kind of just shows all the VMs that you need to deploy Cloud Foundry, along with all the software and all the configuration, like what needs to talk to what, to deploy a Cloud Foundry. And if you were to do this manually, it'd be super complex. Luckily, we have a tool called Bosch, which handles all of this for us. And for those of you who haven't used or heard of Bosch, essentially, you could take like this deployment manifest, which is this huge YAML document. Give that to Bosch, and then it will create all the VMs, upload all the software, and configure it all for you. So to dive a little deeper, this is basically the description on Bosch.io for Bosch. So it's an open source tool for release engineering, deployment, lifecycle management, and monitoring of distributed systems. So to kind of unpack that, since that's a lot of information, basically, Bosch will handle deploying your VMs. So this kind of means creating all the VMs, uploading all the software, which is in the form of Bosch releases, which is just kind of a special format that Bosch understands how to start and stop your software. So it'll take those Bosch releases and start all the software on those VMs and get it configured for you. Second is Bosch will handle the lifecycle of all the software. So Bosch will handle starting all the software and also upgrading and doing rolling upgrades. And Bosch will also watch all your VMs.  And if a piece of software crashes on a VM, then Bosch will also try to restart that software. So Bosch is cool in that it makes deploying Cloud Foundry pretty easy. You just take that manifest and Bosch will play it. But before you even get to that stage, you have to try to figure out, how are you going to deploy a Bosch director? So usually what that requires is a network, usually like a public subnet and a private subnet.  And also some firewall rules to take care of all the configuration. So second, you'll also need some load balancers to kind of expose your apps that are running in Cloud Foundry to the internet. And then finally, you'll Bosch deploy your Cloud Foundry. And so if you even make it that far, you figured out how to deploy your Bosch director. This is great. You now want to deploy Cloud Foundry. You run into a second major hiccup. We said, you know, Bosch is great.  But how exactly are you configuring that deployment manifest? The deployment manifest is a lot of YAML. It's often thousands of lines long. And you have to specify all the configurations for your VMs. You need to say what software you want to run on all of your VMs. You need to tell it the network. You need to get the properties. You need to get the secrets. And there's a lot of places that you could make a mistake. And so this is the second major hiccup that a lot of users previously faced. So even though Bosch is giving you a lot of power in that you have releases that pre-package the software and take away that operational complexity of deploying it, you have this new complexity of making sure that you have all this information correctly formatted. And so we realize this pain. And that's really the motivation for our talk is we want to simplify how you deploy Cloud Foundry. So for the past, I'd say, year and a half, core CF teams have been working on simplifying a setup for Cloud Foundry by creating a set of new tools that allow an easy experience for operators to get from nothing to Cloud Foundry in a matter of a couple of hours. Most of it wait time for VMs and software to be up and running. And so these tools are as followed. First is Bosch bootloader, or bubble for short, which takes you from nothing to having a Bosch director plus the underlying infrastructure you need to deploy your Cloud Foundry. And so bubble is pretty opinionated. It takes a lot of the complexity away from the user.  Under the hood, bubble is using a lot of the new features that are present in Bosch 2.0. And Bosch 2.0 is also heavily used in CF deployment, which is the repository that now houses the main manifests for deploying the Cloud Foundry. And really the power in all of these tools isn't that they each are solving an individual use case in the workflow of deploying Cloud Foundry, but it's how they're integrated and coupled with one another. So for example, you could be thinking about bubble as a tool that gives you a Bosch director. But we prefer for you to think about it as a tool that gives you a Bosch director for the purpose of deploying CF. And we see this through integrations in our pipelines. We'll have pipelines where we deploy a Bosch director using bubble and then deploy CF using that Bosch director. And so we have teams constantly running these pipelines. So we will catch if a change in bubble breaks its compatibility with CF deployment. So it should never hit you as an end user of these tools. These tools should always be compatible with one another for you. And this way, you can then deploy Cloud Foundry in a way that's automatable, repeatable, and reproducible. So with that, we'll dive a little bit into what each of these tools does and what it gets you. Cool. And just to give you a little visual as to what we're kind of describing today, this is a concourse pipeline. And if you haven't used concourse, it's a CI CD tool that we use for the core CF teams to help automate a lot of these tasks. So the first box is bubble up. It's kind of hard to read. But this will create your Bosch director and then deploy CF in the second box to deploy your Cloud Foundry on top of that infrastructure. And then finally, deploying it out. So we're going to dive into that first box, bubble up. So to reiterate, bubble will stand up all the underlying infrastructure that CF needs and Bosch needs for you. And it does that using Terraform. And if you haven't heard of Terraform, it's basically a declarative way to create all the IaaS like networks, firewall rules, subnets, IPs, whatever. And the nice thing about Terraform is that it's also idempotent so that we could run it over and over and we end up with the same state. After bubble creates the infrastructure for you, it'll then create the Bosch director. And this Bosch director is created with Bosch deployment, which also has credub and will also create a jump box for you. So at the end, if you refer back to that first diagram, you'll end up with this state where you have basically everything you need to Bosch deploy a CF. And again, bubble is also idempotent, which is useful for automating this so you could run it over and over again. And you'll always end up with the same state. And it's also helpful for upgrading your Bosch director or whatever infrastructure. If bubble were to release a new patch to fix like a security hole or update your Bosch director, you could just run bubble up again with the new version and it'll update your old Bosch director for you. And it currently supports AWS and GCP, and it currently has partial Azure support. Cool. So once you've bubbled up and you have this Bosch director, bubble also gives you a few helper functions to target this Bosch director, one of which is Bubble Prince Ev, which basically will print out all the environment variables, along with a way to create a SOX5 proxy to your jump box so that the Bosch CLI knows how to talk to the Bosch director through the jump box. The second thing bubble will give you, which is probably one of the more important things, is it'll give you a Cloud Config. So in the Bosch 1.0 world, the manifest had a lot of IA specific information that you had to configure to make sure that Bosch could deploy VMs into whatever network and attach the correct firewall rules for you. But all of that is abstracted out in Bosch 2.0 into this thing called the Cloud Config. And this is attached to your Bosch director so that your deployment manifest no longer has to deal with it. So what this kind of looks like is basically a whole bunch of AZs, disk types, networks, VM types, and VM extensions. And the convenient thing about this is that bubble will, it has a specific naming convention across IAZs to keep whatever deployments against bubble IAZ agnostic, like CF deployment, which gives it an easy way to basically interface with CF deployment. And if you're kind of wondering what this looks like under the hood of that box, it's very simple. It's basically a bubble up and then a bubble create LBs type CF, and that's it. Great. So now that we've run the first box here, we're now ready with a Bosch director and the underlying infrastructure to deploy CF using CF deployment. So what exactly is CF deployment? CF deployment, as I mentioned previously, is the repository that houses the main manifest for deploying Cloud Foundry. And CF deployment really optimizes for several things. First, it really places human reliability at the forefront of the user experience. We really want to make it easy for operators to understand and deploy Cloud Foundry and know what they're deploying when they deploy their CF installation. CF deployment is also on the bleeding edge. So if other teams are releasing new experimental features, there's usually a configuration in CF deployment in order to turn it on and try it out. And with us moving more towards CF deployment, you might not find an ability to turn on that experimental feature as easily using CF release. Also, CF deployment is TLS for all components that can be TLS by default, which is just best security practices. So we're making sure that you, as an operator, don't shoot yourself in the foot. And CF deployment is also geared towards production. So any components that should be highly available are, by default, turned on to be HA and are also streaked across multiple availability sounds. So this all sounds great, right? But you might be wondering, how exactly am I getting all of these features? And so CF deployment really gets a lot of this from things that are in Bosch 2.0. So for example, human readability. How do we really enhance the operator's experience? Well, one way we do this is by having a static main manifest. And the way CF deployment has a static main manifest is due to Bosch 2.0 features, such as a Cloud config, an ops file, and bar store. As Christian's already talked about the Cloud config and how it allows for us to have a static main manifest because of it being i as agnostic, let's dive into the other two. Ops files and bar stores. So an ops file can be thought of as a configuration that can be applied on top of your main static manifest. And so it's usually a short YAML file. We can see an example right here where you say a type. So maybe you want to replace a value in the main manifest and you give a path. So in this case, let's say I want to bump the number of cell instances to a value of five. You then take this file and you apply it to the main manifest, which might say have a default value of two. And in your resulting Cloud boundary that's deployed, you'll have the five instances that you desire. And the really great thing about this is by applying ops files, each ops file can be its own modular configuration. So you could have an ops file that's looking specifically at enabling TCP routing, for example, or an ops file that's looking at disabling the Cloud controller bridge. And so this way, you as an operator, you have the static main manifest. And you know exactly what type of Cloud boundary you're deploying because you can see each of the specific ops files you're applying on top of it. And so this is also great because you can write your own ops files too. So one common thing that I do a lot is I'll have an instance count overrides. So I can put all the instance counts that I want for a particular CF deployment in one ops file. And I know when I'm applying it that I get a different set of instances. And so this really does enhance the user experience. The other thing I mentioned that CF deployment uses is var stores. So before we had, watch 2.0, we had this idea of a var store. If you had something like, say, a database, you had to set all the values in it. And one of the things for your database that you'd have to set would be your password.  I really hope you never did that. More likely, you probably put the password in some other file and use some third-party tooling, such as Spiff, to merge that secret into your manifest. But third-party tooling isn't necessarily made for our use case and could sometimes be difficult to operate. So with a var store, so with the idea of a var store, we now have this main file that will house all of your secrets. And so you can denote when you want to use a value from your var store by giving a special syntax of double parentheses. And that way, Bosch knows to look at your var store to get the secret and place it in when deploying Cloud Foundry. Another really cool thing is if I didn't have, in this case, my DiegoDB password set up before I tried to deploy Cloud Foundry, Bosch would actually generate this secret for me. And this is really powerful, especially in the case of turning on all components that can use TLS to use TLS by default. Because one of the major things that turned people away from using TLS is often making sure that they set up everything correctly, that their CAs, inserts, and keys, all the values are correctly configured. But by having this var store, where Bosch is generating you your CAs, inserts, and keys, you don't have to worry about making that human mistake. And so that's another added benefit. So you might be wondering, OK, I now understand how you get some of these cool features that CIF deployment is giving. How do I actually use it?  And because Bubble now has cred hub support for your Bosch director, it will pull your var store from cred hub. So you don't even have to worry about storing that file in a secure place. And then you have your Cloud Foundry up and running, and you can deploy your apps to it. Cool. And another thing we want to mention is that Bubble also supports concourse. So you'll be able to do a bubble up, bubble create LBs type concourse, and then do a Bosch deploy with a concourse manifest to create a concourse that you can then use to automate your CIF deployment. Release integration, the team that maintains CIF deployment has also published a concourse task that could be used to do basically everything that we've shown in this previous slide deck. And that's what that looks like. So you might be wondering, how are people currently using these tools? Well, the majority of core Cloud Foundry development teams are using these tools right now in their pipelines. So this is one example of a real world use case, which is from the networking team, where we have an environment called Pickle Helm, which is the name of a hat. And we have a Pickle Helm bubble up. So you create your Bosch director for your Pickle Helm environment. You have a Pickle Helm deploy, which will deploy your Cloud Foundry. And then we have a box called Pickle Helm test, which will run the networking acceptance tests against that deployment. We also have a delete Pickle Helm deployment and a Pickle Helm bubble destroy, which will allow us to tear down our Cloud Foundry and also tear down the Bosch director and any underlying infrastructure. Because if you're not going to use this environment for a prolonged period of time, why keep it up and spend money on resources you're not using? Cool. So to end this, we want to talk about some of the future plans that we have for some of these. So first is bubble terraform customization. As we mentioned before, bubble currently is highly opinionated, which doesn't give you a lot of room for customization. So we're kind of exposing some of the templates that we use. The first of which is going to be terraform. Second would be the deployment manifest that we use to deploy jump boxes and the Bosch director. So you can make whatever customizations you want to those. Third is Azure support for bubble. Currently, you could do a bubble up, but bubble create LBs is unsupported. But we also have a team from Microsoft working on getting that into bubble. Lastly is a migration path from CF release to CF deployment. The release integration team is currently working on a way for anybody who's using CF release to migrate to CF deployment. So if you're interested in diving deeper into anything that we talked about today, here are some resources that might be of interest to you. We have the GitHub repositories for all of the tools that we talked about here today, as well as a repository for the CF deployment concourse tasks. So if you want to run any of the boxes you saw in our concourse pipelines today. We also have the Slack channels for each of the teams responsible for each of these tools. And we're really responsive. So if you have any feedback or any questions, feel free to hit us on Slack. It's probably the fastest way to get a response. And with that, we're open to any questions. Thanks again. Thanks very, very nice speech. What about support for OpenStack and VMware? Yeah, we get that question a lot. It's somewhat in the works, well, not in the works. It's an idea. It's on our radar. I think one of the things that suggests, for a long time we supported just AWS and GCP. And one of the things that really helped us start working on Azure support was getting help from Microsoft and getting support from other community members. I know it's on our radar for OpenStack. Visa is also on our radar. But the prioritization, I think, is a little bit up in the air. If you want to push for it, I would suggest going into the bubble user Slack channel. Yeah, so PRs are accepted. Yeah. Of course, I would like to help. But what it means, implementing something in Go or Terraform, or what's the? Yeah, so bubble itself is written in Go. I think, I don't know if there's Terraform. Is there Terraform support for OpenStack? Yeah, so. Yeah, you could submit PRs to add Terraform templates and basically the way to deploy Bosch on OpenStack. And we could pull those in. It'll be a little harder for vSphere since that doesn't have Terraform support. And right now, bubble is pretty Terraform-specific, so. Yeah. Thanks. All right, it doesn't look like there's any other questions. Thank you. Thanks again. Thank you.


This will not be an ordinary governor's budget address. But someone in Harrisburg has to start telling the people of Pennsylvania the truth about the mess we're in. My fellow Pennsylvanians, our commonwealth is in crisis. A crisis that threatens our future. Pennsylvania now faces a $2 billion budget deficit. That's not a Democratic fact, and that's not a Republican fact. It's just a fact. It's a time bomb, and it's ticking away right now, even as I speak. If it explodes, the people in this chamber, if you allow it to explode, then Pennsylvania will experience a fiscal catastrophe, the likes of which we have never seen. Nearly three-quarters of Pennsylvania homeowners will see their already-too-high property taxes skyrocket even further. Our education system, already threadbare after years of underfunding at the state level, will take a ruinous hit. We will lose nearly $200 million in services to Pennsylvania seniors. We'll lose $180 million in assistance for people living with mental illness or intellectual disabilities. Even those cuts will not solve our mathematical crisis. If we don't have sustainable revenue sources in our budget, the result will be billions of dollars in new property tax hikes at the local level. Republicans and Democrats sitting in this chamber right now sat at a table with me and did the hard work to find common ground. We had a deal, and then the House Republican leaders walked away. Only in Harrisburg could that be seen as an acceptable way to do business. And if the consequences I'm describing sound familiar, it's because Pennsylvania has been building up to this moment. For years, our leaders have tried to balance our state budget on the backs of our children. We were left with tens of thousands of teachers laid off. We crowded classrooms across most of our school districts. When I took office, Pennsylvania ranked near the bottom of the country in the percentage of state-level K-12 investment. The burden of funding our schools therefore fell on our local communities. And that in turn meant huge spikes in property taxes for Pennsylvania homeowners. Even these huge cuts to education weren't really enough to balance the budget. Instead of finding a sustainable way to deal with the real deficit, Harrisburg chose to paper over the problem with a series of budgetary gimmicks and quick fixes. Now maybe you can get away with that for a little while, but sooner or later the rent comes due. If you can't agree to the budget reforms I've proposed, then help me find a sustainable alternative. If you won't take seriously your responsibility to the people of Pennsylvania and find another job, a bright future is still within our grasp. It's up to the people in this chamber to save Pennsylvania's future. It's time for the people in this chamber to get back to work. I'm ready to do the hard work to build a brighter future for Pennsylvania. I hope you're ready to join me. Thank you. God bless the Commonwealth of Pennsylvania.


Friends, Swami Vivekananda had great compassion for the poor. He truly believed that poverty was at the root of every problem. Therefore, poverty had to be removed from the nation. He gave top most importance to Dharidra Narayan. From USA, Swami Vivekananda wrote many letters. I would like to refer to the letters he wrote to the Maharaja of Mysore and Swami Ramakrishna Nanaji. In these letters, two clear thoughts emerged about Swami's approach to empowering the poor. First, he wanted empowerment to be taken to the poor if the poor themselves cannot easily go to the empowerment. Second, he said about India's poor. I quote, they are to be given ideas. Their eyes are to be opened to what is going on in the world around them, and then they will work out their own salvation. I quote, this is the approach with which India is moving ahead today. If the poor cannot access banks, then banks must reach the poor. That is what the Jan Dhaniyogana did. If the poor cannot access insurance, then insurance must reach the poor. This is what the Jan Swaraj Shah scheme did. If the poor cannot access healthcare, then we must take healthcare to the poor. This is what Ayushman Bharat's scheme did. Roads, education, electricity and internet connectivity are being taken to every corner of the country, especially to the poor. This is igniting aspirations among the poor, and it is these aspirations that are driving the growth of the country.


If you have the desire, commitment and leadership potential to make a greater contribution to primary industries and rural communities, it's time to let us know. Applications for the 2018 AgriFutures Rural Women's Award open on 14 September at agrifutures.com.au


Hello, my name is Miranda. This is Melissa, Alice, Ethan, and Maddie. We partner with the City of Grand Rapids on a project that is aimed at keeping people in their homes. So Grand Rapids is consistently one of the top five developing cities in the United States. With this growth, we have seen an increase in housing rates to the point that long-term residents are no longer able to afford their rent. And a factor that is adding to this displacement is that financial need in the city is not being accurately assessed or managed. To further explore this issue, we looked at four neighborhoods, Westside Connection, West Grand, John Paul Park, and Swan. This project is important first and foremost because people that have been residents of the city for decades are being forced out of the community that they love. We saw this firsthand when we took a tour of the city's Westside with Commissioner Herbert Hart. We saw that development in South is not the issue, but the fact that development is being implemented in a way that is not either of a use of space or conscious of the economic climate of the communities that they're being implemented in. This project has the power to influence policy and development in a way that allows the city to keep its color and character. It also has the power to influence development in a way that promotes a women's situation where development can still be encouraged, but in a way that positively impacts the community and promotes diversity. So to begin, we had a wealth of publicly available data from many different sources, and our task was to pare down that information to find variables that we thought would best paint a picture or displacement. We initially considered building a model for displacement, but quickly learned that with the data available, it would be difficult to determine forced displacement rather than voluntary location. We eventually decided that the variables that would best paint this picture were demographics, housing costs, and income. We also decided to address the separate but related issue of income by finding means to find median income for these neighborhoods to best paint a picture of the city's financial landscape. So like we're going to mention, the large part of this project was looking at area median income, or AMI, and this figure is used as a benchmark to assess financial aid and housing market rates. And the issue close to us is that the current figure used by the city comes from the Department of Housing and Urban Development, or HUD as well referred to it, and that number is around 69,900 as of 2018. And that number is high to skew because it includes wealthier neighborhoods like ADA and Eastern Rapids. So our task was to try and narrow the scope of AMI down to smaller areas like the four neighborhoods on the west side. And our analysis has shown much lower AMI levels that have gradually increased but only by a small margin, more in the $35,000 to $55,000 range. So as you're seeing the disparity between our target west side neighborhoods and the HUD AMI, we decided it would be a good idea to run a program on the entire city of Grand Rapids, which is represented by deep orange neighborhoods on the right. And we found that the HUD AMI was about $25,000 more than the AMI of Grand Rapids, which is represented by HUD AMI represented by this whole map. And it's clear that HUD AMI is not represented by Grand Rapids accurately. And so when we decided we were going to make this income finder, we had some goals in mind. The first goal was to make a program that you could simply upload in an American community survey, especially your income data too, along with some census tracks which represent neighborhoods, and have a program that would just give immediate income for that area or for those areas. And then after we got that to work, we wanted the program to just make changes to the easiest file format. And so to do so, we wrote the program to recognize key words and extrapolate that directly from the spreadsheet. And then our last goal was to find a school that would be easy to upload to GR data, community platforms. So we wrote it in Python, which is a program that anyone should have things to do. So going a little more depth on how our program works, this top image is of an ACS data sheet when it's first read into our program. And it's kind of messy and there's some unnecessary things that we drop out. But the main feature of our program is reading through this geography column and pulling out the census tracks to create a new index down here for the new gap, right? So that makes it super easy to pull out the rows of data that we need corresponding to what the user inputs. And then we also read through these column headers to pull out income ranges and turn them into much easier numbers to work with up here. And then once we calculate population median, based on the range that falls, then we can turn it into an actual income figure. So to kind of recap our AMI analysis, we found that AMI levels to be much lower than the HUD AMI, more than $35,000 to $55,000 range. And that can have great consequences when we're assessing financial aid in these neighborhoods. So to investigate the extent of displacement that's happening within our four-target neighborhoods of Swan, John Loughard, West Side Connection, and West Grand, we decided to analyze time series data for variables such as median rent values, which we got from Zillow, median income, which we found using that program that we created, as well as demographic data, such as total population, white population, and people of color population from ACS. And one of our major findings was that in all four neighborhoods, people of color are moving out. And in this image, you can see particularly from 2012 to 2013, there's a very drastic decrease in the people of color population, where 40 to 50% of people of color in those neighborhoods moved out during that time period. And such a sudden change in a short period of time indicates that these people were displaced rather than choosing to voluntarily move. And in the years since then, the numbers of the people of color in that neighborhood have not risen back to those numbers seen in 2012. And then another fine day from our time series data was that while median income has fluctuated a bit from neighborhood to neighborhood, on average, I had been fairly stagnant, whereas rent values in these neighborhoods has been steadily increasing since 2013. And looking at rent as a percent of monthly median income in these neighborhoods, we saw that in particular in the neighborhood of West Grand, this percent rose by 8% and in Swam, or it was 10% West Grand and 8% in Swam. So those people of color that were displaced from their neighborhoods may be because they can no longer afford to live there, are very unlikely to be moved back to the places that they call home because it's continued to get more expensive since then. And then to dig deeper into the displacement that we were seeing, we created a program in SAAS that would run cross-correlations between our time series variables. And cross-correlation is a statistical method that measures the similarity between variables and time series data, where if there's a strong positive correlation, that means that the two variables change similar to each other, either both increasing or decreasing. And if there's a strong negative correlation, that means that the two variables change opposite to each other, where when we see an increase in one, we tend to see an increase in the other. And cross-correlation also tests to see if there's a time lag between when we see changes in our data by shifting one of the variables either forward or backwards in time. And at the bottom, we have some examples of what a negative correlation, a positive correlation, and a time lag in time series data look like. So our results from these cross-correlations was that one of them was that there's a very strong negative correlation between white population and people of color population in all four of our neighborhoods. And there's no timeline between maps, so that means that when we see an increase in one population, we tend to also see a decrease in the other population at the same time. And another one of our findings was that there's a very strong positive correlation between the white population and needing income in most of our neighborhoods with no timeline between them. So when we see an increase in one of those, we also tend to see an increase in the other at the same time and same for decrease. But one caveat for our findings is that we only had eight observations per variable in our time series data, one per year from 2010 to 2017. So there was a large error associated with these correlations I've found. However, when we go on to plot the data, we see that these correlations become quite evident. So here you can see the total population, white population and people of color population in each of our four neighborhoods. And you can clearly see that negative correlation between the white population and people of color population and how they're changing opposite to each other over time. So like how we saw that drastic decrease in the people of color population from 2012 to 2013, there's also significant increase in the white population in all four neighborhoods as well. And also notice how the total population has not changed too much over time. So as people are moving out of these neighborhoods and white people are moving in, we're seeing a decrease in the diversity of these neighborhoods. And then here we have the white population and the median income out of our four neighborhoods. And you can see the positive correlation most prominently in John Hart and Swan. And it's also very much that connection, but we did not see that correlation in us grand. But overall, those four neighborhoods, when there's an increase in white population, we tend to see an increase in the median income as well. A couple of this with the fact that we're seeing people of color moving out of these neighborhoods indicates that there's a very strong economic reason behind why we're seeing a displacement of people of color. So in conclusion, the big problem that you're trying to tackle here was the involuntary displacement of people in lower income brackets. The city has a lot of opportunities to make sure that both development and assistance occurs in a responsible and equitable manner. One of these things would be using a smaller median income to assess the needs of individuals in these target neighborhoods. This need may need to be reassessed over time, but we're now, let's see how we're at. Since the semester's only so long, we couldn't look at everything that we found at 16. So if you were to pick this project back up, some variables of interest might be water shutouts, building permits, changes in age demographics, and the percentage of the population spending more than 30% of their income on rent. Second, it would be interesting to characterize low, medium, and high-risk areas in terms of displacement. Finally, we'd like to say thank you to some people who made this project possible, our advisor, Dr. Austin, our advisors with the city, and finally, pick math of the Mathematical Association of America and the National Science Foundation For more information on Mathematical Association of America and the National Science Foundation visit www.mathematical.org