I'm Jessie Toth. I'm known as Jessie++ on the internet. And I'm here to talk to you about easy rewrites with Ruby in Science. So a little bit about me before I get started. Like I said, my name is Jessie Toth Toth. Jessie++ anywhere on the internet that matters. I do a lot of back end Ruby stuff for GitHub related to our giant Ruby on Rails app.  So onto the rewrites. I have to admit that I said easy rewrites, and maybe I lied because you may know that rewrites are never easy. I don't think I've seen any rewrite that's easy. In fact, a legitimate reaction to someone saying they want to rewrite is a rewrite? What? Why do you want to do that? That sounds like a terrible idea, because a lot of them fail. It's really hard to do a rewrite, first of all. They take a long time. They take a lot longer than you expect. Most of them that I have seen, they don't ever finish. You keep rewriting and rewriting and rewriting, and it's never good enough, or it's never the same as the old system, and then maybe you throw away and you start a new rewrite. You rewrite the rewrite, and you just keep doing this. So a rewrite is a pretty scary thing to start. And the rewrite that we did at GitHub was extremely scary, because it was way bigger in scope than anything that I've ever done in the past. But it was pretty successful, because the tools we used. So this was what the rewrite was. We wanted to rewrite our permission system, and we wanted to create a more flexible system to grant and provoke access to repositories, forks, issues, pull requests, teams, organizations, basically anything that's controlled by permissions on github.com. And that's scary. That's pretty far-reaching.  So touching a lot of stuff. But to understand why this was necessary, I want to give you a little bit of history of what the system was before we decided to rewrite it, and why a rewrite really seemed necessary. So first, there was collaboration. When github started, we let people collaborate with one another. And there was a feature you could add someone as a collaborator to your repository and give them access to your code. And you could use pull requests or use things to collaborate back and forth and work on the code together. And as github grew, the original collaboration was not enough. It was basically just two or maybe three people working together. But people started to have teams, or they started to put their companies on github, and they needed more effective ways to organize the sort of access and permissions. So then we added organizations. These were ways to group your teams together and give them access to different repositories that your organization controlled. But there were problems with this from the start. One of the biggest problems was that these two systems, they came in at different times, and so they ended up having different ways of granting permissions to things. The old collaborators, they granted permissions one way. In fact, the table looked kind of like this. It was a super simple joint table. It said this user has access to this repository, and that's it. But then when we did organizations, they implemented it a slightly different way, which was team members. If you look at this closely, you might be scratching your head, and you might notice that this is a three-way joint table, which is pretty terrible. It's joining on a team, a user, and a repository. So here, users could be a member of a team. That's how you said you were on a team. But a repository could also be a member on a team. That's how you said this repository gives access to these team members. It wasn't the best schema, and it cost us a lot of problems. Places where it started to cause us problems were places where we needed to get lists of things. So there were a lot of places that needed lists of particular repositories, lists of pull requests you had access to, or scope to this thing, lists of teams even. And they all needed to access the permissions in slightly different ways, depending on the kind of data they wanted.  You need to get those in one way, versus if you're going from a user perspective, what pull requests can they access? Well, those might be different based on whether they have access to individual repositories as a collaborator, versus through organizations. And as time went on, we found that there were a lot of bugs around different educations and transitional states. We actually have a lot of transitional states in GitHub. You can be added and removed from a team. You can have your access removed. You, as a user, can transform yourself into an organization. You can transfer your repository to another user. You can do all these crazy things. And there were lots of bugs and lots of craziness. So we started to see issues like this. People could see things on this dashboard that they didn't actually have access to. When they got these lists of pull requests, it said, you can access this one. But he would click on it and go somewhere into a 404 and say, oh, sorry. When we get to this page, we finally discovered that you no longer have access. And we kept seeing these sort of problems. In addition, we started to see a degradation of performance. As GitHub got more popular, there were more repositories to be pulling in. There were more issues. There were more pull requests. There was a lot of stuff to be grabbing. And each of these places, they all grabbed these lists in different ways. And they all started to have performance problems at different times. So different people would come in and say, oh, there's a performance problem here. Let me optimize it. And each person did this a little bit differently in each place. But they all ended up kind of like this, these giant hunks of optimize SQL. And this isn't very pretty, right? And each of them were slightly different because a slightly different person had come in and optimized this one, and it's grabbing slightly different data. So all these things kind of compounded together and already gave a good reason to rewrite. But we had one more thing to add. Defunct Chris Wainstroth, our CEO, said, you know what? Organizations aren't even good enough yet. We want to make them better. But when looking at the permission system we have, we can't possibly add anything to it. It's already so complicated. If we wanted to, say, change our permissions, we can't do that. I'd like to do that. Let's find a way to do that. And so we said, OK, we have to do a rewrite to do that. If you want that, you must let us rewrite. All this history that I've given you actually happened before I even joined the company. So I'm telling you the story of these two heroes right now. This is John Barnett and Rick Badley. They started off at the beginning of the rewrite to replace the system and see if they could make something better. So they started off with some pretty simple goals. They wanted something much simpler than what we had and much more flexible so it could be extended to different things that in the future we may want to grant permissions for, just any general permission. We want it to be fast. We want it to be super fast. Some of these things had already had permission problems. GitHub was continuing to grow and seeing bigger and more complex use cases. So they need to be fast now so that they would continue to be fast in the future. And we also wanted to make it pretty easy to operate with the things that we already had. GitHub's pretty conservative about our operation. We don't like to add new databases or new technology. We tend to stick to what we have. So we said, the old thing was in MySQL. Let's write this new thing as a table in MySQL instead of maybe going for a graph database or something like that. So they started off with an initial spike. And they wanted to be able to spike something out quickly to test how it would perform with load data as quickly as possible so they didn't get too far into writing something and then realize that it wasn't going to work. It turns out this was a pretty legitimate concern. So they wrote something that they called capabilities. And this was going to be the system that we were going to use. And John started off writing this and saying, this is how it's going to be. You ask the capability. Can this user do this thing? Can this object do this thing? But in order to test this, he was doing the rewrite. And we also needed to do a refactor because in order to test it out with production data, we needed to wait until kind of shim it into the areas that were already reading permissions and just maybe dark ship it a little bit, run it, see what it was doing versus that. So while John was writing the new system, Rick was trying to refactor just a few key touch points so that we could put this in and see what it would look like if we were to switch over it. But he ran into a problem while he was doing this refactoring. He was finding places where there were some tests, and maybe there weren't as many tests as we wanted, but the problem with the test is they also weren't modeling production data. We'd been seeing these scenarios that were really complicated and maybe they were from people that had been users since the beginning of GitHub and they had accumulated all this data. And no matter how we tried, we couldn't get these test cases into our tests to show the same sort of things. So what he decided to do was to run a little bit of experiment. He wanted to conditionally execute a path that he had tried to refactor and see did this refactoring return the same thing that the original thing did, which is usually what your tests do. But with such complex data, we said we actually need to test this in production to see if it really is doing the same thing. So that's what he did. He basically dark shipped this little refactor, and he used the instrumentation library we have to just throw off some events any time it was run. So he started off running it very few times, like 1% of the time maybe, and comparing the results at the end, returning the original code, but doing some timing and some measurement around what happened with the refactored path.  He was able to see, oh, I didn't quite refactor this correctly. I forgot this little case. And he was able to fix that. And he kept doing this. And it turned out it was really useful. So we pulled this into a library and called it Science. And we made it available to everyone at GitHub, because we said this is really useful, actually. You should try science and everything. You should run experiments on all of your code and see if this works for you. So let me run through an example of what science looks like. We have a repository class in our models. And here's a question that we asked repositories a lot.  Can they pool your code? And to put a science experiment in there, what you do is you say, I want to make an experiment, give it a little name, string. And then you take the old code that used to be in poolable by, and you put it into a new method. We came up with this convention just taking the same method, throw legacy on the end. So poolable by legacy, you take that code in there. And you say, OK, for the science experiment, I want you to use this legacy code. But I also want you to try something new. Try out this new code that I did. This is just an experiment. We want to see if it's going to work. And you can add some useful things to it, like a context. We said, here's the repo we're trying. Here's the user we're trying. So if these things don't match, then we can use that context to go back and investigate and see what was happening. So each experiment would publish this. And we passed that to our instrumentation library. And we were able to gather some really neat things here. So we could see the total amount that we were running this. So how many times did this get called? We grabbed some timing data around it. So how long did the old code path take? How long did the new code path take? We also threw a custom event whenever things mismatched. So when things did not match, increased the total of how many went wrong so you can keep track of how often you're mismatching. And then we just did something super simple, where we just dumped the payload into Redis so that we could go and look at it later. And said, OK, if we have a mismatch, we want to go and investigate that data and see what went wrong and use that to go back and change the code. So they used this process over and over again. And they were able to get a decent spike out. Now, it didn't quite work. It had some performance problems. So they stopped and they threw it away. But they stepped back and took the lessons that they learned from that to build a new system. So this is the part of the story where I come in. I had just joined GitHub at this time. In fact, Nathan and myself both joined GitHub at this time. And we were asked if we'd like to join this project. And we sat down with Rick and John, and we talked through some of the lessons that they learned from capabilities and said, OK, we want to build a new system. We'll give it a new name, too, so we don't confuse ourselves. We're calling it Abilities. And so we're going to take everything that we did wrong there, and we're going to build this new system. And we really want to actually put it in now. I think we're ready. So what we came up with was something super simple like this. And it's basically, you ask a question to the system. It says, can this user read this repository? And we generalize that quite a bit. So you have a general actor. It could be a user. It could be a team. It could be an organization. And you have a subject. It's a repository in most cases, but sometimes it's a team or something else. So you can ask questions about it. You can grant things. So a subject will grant an actor a specific action. And you can revoke those things. So this was super simple. This is basically all we came up with. We had to add a little bit more. We had situations where we have users and teams and repositories. So if you grant a team access to a repository and a user access to a team, we wanted that to cascade so that the user got the access to a repository. But beyond that, that was the whole system. That was it. And we thought it was super simple. And it would maybe break down some of those huge queries that we were seeing. So we went through this. And we wrote the core of Abilities the actual rewrite in maybe a few months. There was a bit of iteration on it and figuring out what we wanted to do. We went off into the weeds a little bit. We tried to make it too general. And then we came back and said, no, we really need this. For this specific case, let's not go too crazy. But that actual rewrite didn't take very long. What did take long was the next part, which was modeling that to our legacy data. So once it was written, we said, OK, we need a way to see if the data generated by this system is the same as the old system. So we just wrote some little migration scripts. In the beginning, it was the GitHub org. Run through the GitHub org. And for every user and team and repository on there, try to generate the type of permissions in the new ability system that it has based on the data that we have in the old system. And when we ran through that, we saw a few problems. We fixed them up. But then we opened that up and started running the migrators for everybody on github.com. So let's generate the data for everyone and see, does this match our old system? And after generating the data, of course, we started off with generating the data. And that was good. But data changed from the time we generated to the time we were measuring at times. So then we added places where we were dark shipping rights to abilities. So any time you touched the old system, we said, write this also to abilities. Write a new record. Or if you're removing something, delete the record. Just do both of them at the same time. And we kept this dark ship scaled down a lot. We would do it maybe 10% of the time or something like that. We always wrote, but we didn't always read. We didn't want to put too much load on the system. But once we had that in, we wanted to science everything. So we wanted to add science to everything. So any place that we read data out of the permission system, we added a science experiment. And we said, OK, keep reading the old system. But now start reading the new system and tell us what the differences are. And that's the point at which we could start looking at all this data that we had generated and seeing what we had. So it looked kind of like this. We built this dashboard to show the graphite data that we had. Our instrumentation all goes into graphite. So we had graphs and stats on how many mismatches we had, how much is this running, how many total things. And we could, at a glance, see how all our experiments were doing. So this was a health check. Every morning I would get up and I'd say, OK, how's abilities doing this morning? And I would look at one specific experiment. I'd drill down in and I'd say, OK, how's poolable by doing this morning? Well, we're running quite a few of them. You can see the top graph is how many total times the experiment has been run. And then it has a little line on the bottom for wrong. But because there's such a huge scale between wrong and total, you can't really see it. So we made a more zoomed in graph below that, which is how many mismatches you have. And then we also cared a lot about performance, especially because we had this dark shift. We can't have this being very slow. So we also had graphs for what is the performance of the new thing that you were trying out versus the old code. And we just kept looking at this. And once we saw the mismatches, then we wanted to actually analyze what we had. So we said, OK, there's about 20 mismatches per hour. What are they? What's happening? What's going wrong? So at this point, we did this super simple. You can just jump into the console and pull these things out of Redis and say, OK, how many times has pooled by a mismatch? We've got about 3,000 results waiting for analysis there. And you can just pop each result off. And what it looked like was a super simple hash. It said, this is the experiment we're running. And then it had some things for the candidate, which was the control, which was the legacy, and the candidate, which was the new thing that you were trying. So it would show you how long did it take? Did it raise an exception? And what was the value returned? In the case of pooled by, this was just a Boolean method. So it was true and false. But with the context that we added to this, so we had the repository and the user, then I could go in to the Rails console and I could start investigating. I say, OK, what happened to this user? I could walk through the legacy code of pooled by, line by line, and say, OK, well, it matched this condition, this condition, this condition, and this is where it went to mismatch. What went wrong there? So what we found were a few things. There were definitely bugs and abilities at first. Like I said, we hadn't completely modeled the old system correctly to begin with because we didn't even have the whole thing in our head to begin with. So at the first time when that happened, we would fix a bug. And then we would say, OK, we've run our migrators, we had all this data in the database, let's just truncate the whole table and re-run the migrators and fill it up again. Because at that point it was a bug in the system itself, not anything else to fix. But once we got past that, that didn't take too long, then we had something more, which was problems with our data. In fact, we ran into a lot of data quality problems. I can show you a, this is going to go. Sorry. It's a sampling of the data quality issues that I saw. There were a lot of them. And this is where we spent probably a bulk of our time. We found quite a bit of problems in the data that we had in the database for the old stuff. People had had something wrong. Maybe they fixed the bug, but they didn't know that it had generated a whole bunch of old data that was really bad and they didn't clean it up. And that data just kept going. It interacted with other data and got uglier and dirtier and more terrible. And so we had to track it down, each and every case, and find out why it got that way, how it got that way, and fix all of them. When we first saw these data quality problems, we thought maybe it's one or two things. We can just ignore it, switch over to the new system. It'll be fine. No, it was definitely not fine. There were a huge amount of data quality problems. So we said we need to fix this in the old data in order for it to generate new data correctly. And we need to be sure that they're both matching and true and correct for the right reasons. And because we did this so often, we ended up writing a lot of tools to help with data quality. We wrote a library for running data transitions because we did it so frequently. It used to be we'd just run rails, migrations, but that was too brittle for us. We needed to be able to run them in parallel. We needed to be able to run a lot of them at the same time. We needed to be able to throttle them. There were times when we were deleting millions of rows and we didn't want to be attacking our database just because we're doing this maintenance to clean it up. So we built throttlers to run this slowly over time and get rid of it without anybody noticing. We also have problems with just the legacy system itself. There were some things that just weren't thought out. There were features that were added together that didn't work together properly. In particular, I ran into a problem with networks of repositories and forks when they had different visibilities. Some were public, some were private. The permissions were just totally messed up. So I had to stop working on abilities and I had to go fix that. I had to fix the code. I had to fix the data.  It was long and it wasn't involved, but we had to do it to move forward. Otherwise, the system, it just wouldn't have worked. We wouldn't have been able to generate the right thing. So we got through all that. And then we ran into some other stuff. So like I said, this was dark shipped and we were watching the performance the whole time. In general, the performance was good, but we started to see some interesting cases. The graph up there in the top showed something that started to happen to us every day at 5 p.m. We had this one particular customer that was doing something very interesting with our API and they were mucking with the permissions every day at 5 p.m. and they had teams and repositories sizes that were much larger than we had dealt with before. And they were making a lot of changes. They were basically trying to delete all their permissions and put them all back one right after another, which sounds terrible, but we ought to be able to handle it and we weren't. Abilities wasn't handling it. The old system seemed to do it just fine, but abilities wasn't handling it quite well enough. So we went back and we reworked abilities. We had, we were blowing out a lot of stuff into the database and we found there was a way that we could infer certain things. We didn't need to write rows. And what that ended up doing was we were able to delete 72 million rows of these things. And you can see the graph that Nathan shows there. The next, after he finished this the next day, there was no blip at 5 p.m. So having that dark shift was super helpful for us. We could work on the performance over time and then we could see things as soon as they happened.  We could see this slowly as we were ramping up. We could even turn abilities off completely so that if we really didn't want this to happen, we could just turn it off and not have performance problems at all. So that was really helpful for us in developing it. So at this point, where are we? We've done a rewrite and a refactor and a bunch of science and a huge amount of data quality repair and some performance. And it's taken a long time. This is probably close to two years in and this is where our progress is right now. None of these things are using abilities. But we just kept going. We kept doing that loop over and over again, you know. Have the data in there, read it out, find the mismatch, just find the data quality problem, fix it. It's over and over again. This was my life for months and months and months. But finally, we were able to start flipping things over and we did them piece by piece. We started with organizations. So check, we got those. Then we did teams. That wasn't too bad, check. But the big thing that was left was repositories. And this was the biggest thing that got us into this problem in the first place. So, and it was a place where we had the most data quality issues. So it was gonna be the hardest. It was gonna take the longest. We're expecting this, but we kept working through it and eventually got to the point where the science was mostly green. There was one last data quality issue. And the problem was that when users were being deleted, they weren't being removed from teams so that wasn't being cleaned up. It was just some legacy data that was there that we weren't gonna do that in the new system. So I said, okay, I'm gonna write a data transition like I have before to clean this up.  That doesn't look right. I ran another query.  I just deleted every single repository from every single team. I mean, this is the reason we wanted to refactor this. This three-way join table was so bad that it was really hard to write the correct query for it and it bit me. I mean, one last time before I could get out, it bit me in a really hard way. And so you can see, I mean, we put up a status. We said, some of you may not be able to access your repositories. But, but we did have abilities. And I said, you know what? Well, we have backups for our database and our database administrator is fantastic. Like he was right on. He's like, okay, we'll get this. We'll get all the data back in. And I said, while you're doing that, I'm gonna turn abilities on. I'm gonna switch it over to the new system because it's pretty much ready and right now it's more correct than the old system. So I did that. We got to have a little bit of a fire drill with abilities. And so they got all the backups there and got all the data back. And I said, okay, I'm gonna revert that because I'm just not confident that we should leave it on. I wanna be absolutely sure we should leave that on. So once I cleaned up my mess and got all that ready, I went back and I looked at the experiments. I said, well, we're all green now. That was the one last data quality thing I had to fix. But I was a little gun shy, especially after what had just happened. So I said, all right, I wanna be really sure. I wanna be scientific about this. I wanna do something that runs through every single user in Repository and calls us to be sure that there's no bad data sitting there that we just haven't hit because nobody's brought it up in production. So I made this transition. I said, I'm just gonna iterate through each of them. I was expecting data quality problems to come up. I was like, this isn't gonna be the end. I'm gonna find something else, I'm sure. But I didn't. I ran through all of it and there was not a single mismatch while I ran through it. And so I said, all right, guys, it's time. Let's switch it over. And the way we did this with science is just to be sure we would actually switch the use in the tri-blocks. So we'd say we'd keep everything the same but switch what the control and candidate we're doing just to be sure that we could still measure performance and see that there were no mismatches happening after the switch. And then once we were extremely competent, then we would remove the science. So at this point, we've done it. Everything, organizations, team, repositories, it's all using abilities. This happened mid-August and besides that little blip where I removed your access to repositories via Teams, you shouldn't have noticed. We open sourced this library because this was tremendously useful. I cannot even imagine doing this sort of rewrite without having this tool. I mean, it helped us to write the original library. It helped us to find massive amounts of data quality. It helps with problems in just the logic itself. I don't know how else we would have done it without this. So if you're doing a big rewrite with this, I would recommend that you use something like Scientist or use some sort of data and graphs and be very, very sure. And I hope that you use it. Thank you.


In practice problem 2, we're asked to find the radius of the base of a cylinder if the surface area is 528 pi square feet and the height is 10 feet. If you don't know where to start on these kind of problems, shall we start with the formula? We're asked if we're talking about the surface area of a cylinder? So I'm going to start this off by writing out the formula for the surface area of a cylinder and go from there. The surface area of a cylinder is 2 pi r squared plus 2 pi r h. And then let's look at what information is given to us. We're asked to find the radius. So I'm going to circle the r's because that's what we're going to solve for. And then we're given some pieces of information. We're given that the total surface area is 528 pi. So we're going to plug that in for the total surface area. And we're also given that the height is 10. And that's over here the height being 10. And then we're just going to fill in the rest of the formula and see what we have. So the total surface area 528 pi equals, we're going to leave it in pi form 2 pi r squared plus 2 pi r times h. And I'm going to go ahead and simplify this. I have three separate terms. 528 pi cannot be simplified anymore because we're going to leave it in pi form. 2 pi r h is simplified. But I have 2 times pi times r times 10. So I'm going to combine the 2 times 10 equals 20 pi times r. So now I have this equation and the only missing values are r. And that's what I'm trying to find, the radius of the base of the cylinder. And I'm going to simplify this even more. If you see each of these three terms has pi in it. So I can divide by pi and get rid of the pi to simplify this. And you'll also notice that each of these numbers is even. So I'm going to simplify that further by dividing out a 2. They're all divisible by 2. So I can clean up this equation. If I divide everything by the same thing, 2 pi, you'll see what happens here. The pi's are going to cancel in each of these terms.  And then 20 divided by 2 of course is 10. And I have the r there as well, 10r. Now that I've cleaned that up, it looks a lot easier to solve. And you should notice that this is a quadratic equation because I have a squared term r squared plus 10r. And then the constant number 264. If you see an equation that has a squared term in it, that should be a clue that you're going to factor this and we're going to put it in standard form and see what we have. To put it in standard form, I just have to move that 264 over, set everything equal to 0, and I'm going to have r squared plus 10r minus 264 equals 0. And now I can go ahead and factor this. This one's a little tricky because 264 is a pretty big number. We have to find the factor pairs of 264 that will add or subtract to 10. Why don't you pause the video and see if you can play around with some numbers and come up with the factor pairs that will work for this equation. And the numbers that work for this, the factor pairs of 264 are 22 and 12. That may have taken a while to get, but if you play around enough you'll get that because the difference 22 and 12, 22 times 12 equals 264. And then to get this positive 10, I would have a positive 22 and a negative 12. So when I factor that out, it's going to be r plus 22, r minus 12 equals 0. And to solve that then, my final answer r equals negative 22 or positive 12. And then the final step is to realize that what we're asked to find is the radius of the base of the cylinder. We can't have a negative distance, so we can't have a negative radius. And so my final answer is just going to be r equals 12. The radius of the base of my circle is 12.


O say can you see by the dawn's early light, What so pride at the twilight's last gleam's broad stripes and bright stars.


Monday, November 22nd at 5.45 p.m. via Google Meet and Bethel campus agenda call to order any adjustments to the agenda. I do not imagine so let's keep going discussion 3.1 career change assistance program take it away Jamie all right so per the master agreement each board in the SU have to act on whether they're going to offer the career change assistance program opportunity for our faculty we at least since my 10 years started no one has we hadn't been in a place financially to feel like we could budget accordingly to support that just so folks know that article 17 does allow for any faculty member who's been with us 15 years or longer to apply if you do grant the opportunity to participate with that results in is a one-time so for the following year their salary 80% of their salary and for one single-planning single-healthcare plan and so you know we plan on you know when you think about salary and benefits about 80,000 for a teacher and so you'd be thinking about 80% of that if you were able to to allow for that and so we have not in your current budget what you've been seeing plan for that and so if you took action tonight in the wood budget accordingly if that was the case is it the negotiations committee recommendation that we do this I'm not in a place to talk about that publicly right now oh okay so shouldn't we be an executive session to talk about this no you should be taking action on this publicly that's it right now that's this year you're asking me what's the negotiations team thinking about in the future well I guess no I guess I'm confused is this in the current contract yes okay just so I understand so it's in the current contract but it can't be offered until we approve it and why did we approve it if you approve it or not offer you have the option every local district board in the current master agreement as the opportunity to offer this opportunity first down Robert go ahead yes as I understand from the language of the contract it's the hit will not be just will not be next year it will be 80% of the staff of the last year's salary and that'll be spread over three four or five years per the teacher's option is that correct yeah so what our financial the worst that our financial obligation would be in the fall in this the following year would be a third of the salary so yeah plus one one cost of health insurance what I would say is is that typically when I see these types of plans they are typically to support the idea of it's called career change assistance what I've seen them be is more of an opportunity to say to a teacher that maybe who are feeling like teaching behind them a way for them to feel like they can financially move on and what I'm very comfortable saying in public session is is that we have teachers who are feeling like this is no longer the ideal fit we should be helping them realize a position that they do feel is most supportive to wherever they're current and their current pursuit realize and I don't think we should be saying we'll provide a financial means to pursue so if you said to me then what do you advise I would certainly devise that we decline I'm sorry I missed the last part of that it faded out I would advise that we decline in offering this okay thank you that's what I'm because I'm not familiar I mean I like the idea of sabbatical in the sense of this is very different from that yeah got you okay that's what I was thinking this was that's that's no okay for the questions Amy justine Robert mayor you want another comment yes I want to point out in in history we had a similar a similar offering in the far past and hoping that some some particular teachers would take that option in fact our very best teachers which we hope to retain took that option so you have it needs to be taken very offered very judiciously so just a great point as well Robert again just because I'm thick and I like to understand things if we reject this it means that it can't be offered to anybody right right okay so we have to approve it in general and then a teacher applies for it and then we would say yes or no after we've approved it I don't think we have the option once the teacher applies to say yes or no they can take it if a teacher applies thank you that's this is this is the clarity I want on the record for us so we know what we're doing because is there a limit to how many teachers can apply I do believe there is and I do not bring the master agreement with me tonight so I apologize actually I have it right here I lied sorry it's been it's been a busy day folks I can imagine we're ready to move this motion yes I'd like to make a motion that we do not offer the career change assistance program second second discussion being none all in favor signify by saying aye aye aye aye aye aye oh aye him disappiors as say, if you want to pull up the agenda, I can, I muted you on purpose. I think it's over his computer. Yeah, I can pull up the agenda. See what was on it now. Action and then public comment. Okay. Oh, there's Ethan's back.  We're about to do public comment. Can you just so just to add it is not captain's for any teacher over 15 years. You think you're muted? Immuted you. Okay, great. Any public comment? Being none. Motion to adjourn. There's no adjourn on this agenda. So we'll assume that that's understood. All in favor of adjourning. Signify by saying aye. Aye. Aye. Good. We're up. Thank you all for making time.


This study aimed to develop a peer mother training program to improve post-discharge care for low birth weight, LBW, infants in rural Kenyan communities. The program was designed to equip mothers with the necessary knowledge and skills to provide supportive care to LBW infants and their families. The study found that the peer mother training program successfully equipped peer mothers with the necessary skills to provide supportive care to LBW infants and their families. Additionally, the study showed that the peer mothers felt empowered to promote appropriate infant feeding practices and engage in other health-seeking behaviors. Overall, the study suggests that community-based interventions for LBW infants, delivered by appropriately trained peer mothers, can be effective in improving post-discharge care for these infants. This article was authored by Gemma L. Wright, Florence Akeying, Linda Tindy, and others.


Hi everyone, I'm Kat Manyalek, and I'm a partner at Y Combinator. So at YC for those of you who are not super familiar with us, we fund startups. Since 2005 we've funded about 1,500 companies and 3,000 founders. And in the last batch about 40% of the companies that we funded were from outside the US. So I'm excited to meet a lot of you here today who are pitching your startups, and I hope you'll apply to YC. So these are some of our alumni. We have Dropbox, Airbnb, Reddit, Cruise. We've funded our companies now have a combined valuation of about 85 billion dollars. And actually Reddit is the reason why I am here today and why I am at Y Combinator. So to give you a little bit of background on myself, before YC I worked at Wired Magazine. And then after that I was a chief of staff to Alexis Ohanian, the founder of Reddit. Reddit was in the very first batch of YC. It was the very first company to get acquired at Y Combinator. And essentially I learned, I worked with Alexis on his fund and nonprofit. And what we ended up doing is we helped a lot of his portfolio companies pitch and figure out how to build their communication strategy, how to launch. We worked with hundreds of companies and I learned not only about community building from Alexis and he's one of the best in the world. Reddit is now one of the top five sites in the U.S. But is also a great startup storyteller. So that's what I'm going to talk to you a little bit about today. I'm going to talk to you about how we advise our companies at YC to pitch, to pitch VCs, to pitch you know, press, to pitch people who get pitched tens, if not hundreds of times a day. How do you pitch a company in a way that is going to be viral, that is going to be compelling, that'll stick in investors' heads? So I just got out of reading, you know, YC gets about 7,000 applications per batch. So we read hundreds and hundreds of applications every six months. And so I'm just coming off of reading a lot of pitches. So this is all very fresh. And so let's, so to give you a little bit of background on what I do at YC today, part of it is outreach. And that means outreach to potential applicants, getting more of the best people from around the world to apply and join the program. Then while the companies are in YC, I help them a lot with this sort of stuff, with figuring out how to tell your story, how to tell your story to press, pitching them, getting them launched. And so let's talk about how to get your pitch and how to make it viral. So in Silicon Valley, we often obsess over this number. We often think about how do you get to a billion dollars, a billion, you know, customers. How do you impact a billion lives?  And maybe my mom, that's my mom. And so at YC, we often focus on this number. We focus on a hundred. How do you get your first hundred users? And one of our partners, Paul Buhite, who's the creator of Gmail, likes to say, you should focus on building something that a hundred people love versus a thousand people just kind of like. Because those hundred first people who love you will become your evangelists. They'll kind of talk about what you're building. They'll talk about it. They'll become your viral sales force for you. And so let's talk a little bit about what you have to do to get those first hundred people that absolutely love you. And I'll just go over two things since we only have a little bit of time. I'll go over one, clarity of vision and how to communicate that. And then two, I'll tell you the real key to making something that people love. And so first, let's talk about clarity of vision. So clarity of vision is really important because a clear idea is the foundation for growth. So we believe a person who has thought deeply about an idea can explain it clearly and succinctly. They can explain it in a way that a five-year-old can understand, in a way that a five-year-old can describe what you're doing. And so they use less words. They can explain these concepts, complex concepts in a simple way. And so basically this is so important because you're going to have to communicate as a CEO or founder of a company this vision in order to recruit co-founders and investors, users, employees, and shareholders. You're going to be having to do this for the vast majority, for the entire life of the company. And it's also really important. It's necessary to make it really, really easy for people to, sorry, having to go back, for people to talk about what you're doing. Because when people sit around, if you think about some of the best companies or the companies that you use every day, think about how you learned about Snapchat or Facebook. More likely than not, you learned about those products through friends, through hearing them from friends or family or people that you came across talking about something that they were excited about using. So when people sit around their dining table, it should be you and your company and your app that they're talking about. They should be able to deliver your short pitch for you. And so you don't naturally have to be good at pitching your company. The vast majority of the founders that we talk to, it takes the months to really hone the messaging and to get it down to just one sentence that can compel someone to invest in them or to write a story about them. So here's how we think about starting to craft that memorable pitch. So first, we recommend men that you lead with what, not with why. And this might seem counterintuitive because if you think about storytelling, we like to tell stories chronologically. So a lot of people like to start with how they came across the problem that they're solving and why the problem is so big. And the reason that many of you do this is that because you're all very ambitious people, you want to solve these big problems that are plaguing the world and you're really excited about why. But here's the problem. If you've already gotten 30 seconds into a pitch and you're talking about the problem and I still don't know what you or your company does, I've zoned out. So for example, someone will say, my mother was a small business owner and I saw her spending 30 hours per week, like blah, blah, blah. And you've already zoned out. I have no idea what this company does. And so I would recommend starting with one sentence that tells your audience what it is you're doing and then you can give them more backstory once you have them hooked. So here's a second problem that I come across pretty much every day is meaningless jargon. So this is a tweet from a former partner Gary Tan who used to work with and he's expressing a pain that I feel acutely. He said, meaningless jargon is the number one issue I spend time trying to fight when helping startups. We read so many pitches that have zero informational content in them. So for example, here's an actual startup pitch. IndieCloud is a know-how and synergy platform.  This has zero informational content. You have no idea what IndieCloud does. So IndieCloud, one way that you can tell whether your pitch is good is if someone in the audience has some idea of how they might replicate the idea that you're trying to communicate. So IndieCloud as a know-how synergy platform could be something like Slack. It could be something like a sauna. It could be one of thousands if not millions of products out there. And so what you want to do again is to try to communicate an idea that your audience or even your audience of one can figure out how to replicate in their head. And so this is another thing that I recommend you not do. Ramble. If you make it 30 seconds and there's a long preamble, you've already zoned out. So here is the actual pitch that Airbnb used on their YC application. We built the first online marketplace that lets travelers book rooms with locals instead of hotels. That's pretty straightforward. It's descriptive. There's no jargon. There's no long preamble. You can tell what they do. You have a sense of what you need to build to replicate this. I think it's a really tight description. And so for us when we're reading applications, we're reading hundreds if not thousands of applications, we have to understand in that first sentence what it is you do or we sort of lose focus. So here's an example of a company that went through Y Combinator last year. Calor is the Fitbit for dairy cows. So I found this one when I was looking through applications super compelling. And so one of the things that I would say is it's pithy, it's short.  So when I saw this, I was like, I have so many questions. I was like, why do dairy cows need to track their health? And why does anyone need to monitor it? And how big of a market is this? How big of a problem? And so that's what you want to do with your short pitch. You want to hook someone. You want to compel them. You want it to be short enough for them to follow up. You don't need to give them all the answers up front. You want them to come at you with the questions. And so here you can sort of understand what is, you know, the problem they're trying to solve and who they're trying to solve it for, which is the main thing you want to get across in this pitch. And so some people ask me whether this X for Y construction works. And by that I mean X for Y being Uber for X or Airbnb for X. Some people say, should I not use sort of this analogy because it's cliched or overused? And let's be honest, like we've all heard too many pitches for Uber for X, right? Everybody's heard like everyone's like doing like Uber for X or, you know, Tinder for X. And so it is oftentimes or maybe perhaps most times overused. But there are some good reasons to use this X for Y convention. And so here, for example, is a YC alum that went through last year. Right Electric is Boeing for electric airplanes. They describe themselves as Boeing for electric airplanes that I feel like that paints a pretty clear picture of what they do. And it uses very few words. And so I think that it's, it works like the X for Y analogy. If it is the best way to paint a clear picture of what you're building really quickly, I think it makes sense to use it. But you know, and here are some rules, if you're thinking about calling yourself the X for Y, the Boeing for electric airplanes, if you're using this construction, here are some of the rules you should follow. X should be a household name, something that is universally recognized.  So for example, another company that went through YC last year was Salesforce for churches. Like that, you know, churches to me, that seems like a really, you know, huge market, which is number three. And it also seems fairly reasonably obvious why churches would want to track all of their, you know, all the people, their constituents essentially. So it should be fairly obvious why Y would want X and it should be clear that Y is a huge market. So here's one that I didn't love that went through YC last year. Originally, they called themselves Buffer for Snapchat. So Buffer is a company that's doing reasonably well, but I, you know, most people, it's not a household name.  And it's not a good reason to use this construction. And so to review, the best short pitches are descriptive. They're conversational. You don't use any jargon. There's no long-winded preamble to get to the point. And it's concise. And so now that you sort of know how to build a great short pitch, I'll talk to you about the real secret to building something that people really want to talk about and are excited about. And that's essentially making something people want. That's YC's motto. And so that's one of the things that we really focus on at YC is, are you actually making something people want? And basically, the way that you know that you're building something people want is actually building a product, even the very first early version of it and getting it out to users. That's, those are the two things that we say you should be doing during the YC program, the only two things, building products and talking to users. And so what you'll want to do is get that early product into people's hands and watch people actually use it. Sit down with them, offer people in a random coffee shop, offer to buy them coffee if they'll look at your product. Do anything you can to get some actual real strangers using your product, rather than your parents or your friends, because they're probably not going to be that honest with you. So this is going to be obviously manual at first, talking to users, but as a startup, as a startup founder, you have, that's one of your superpowers. You can do a lot of things manually that big companies don't have time to do. So let's see where we're at. So to recap really quickly, as I was saying, a clear idea is the foundation for growth and communicating that as simply as possible so that anyone can understand it and pitch it for you, pitch it back to you, is the way to like lodge yourself into people's brains. And then second, of course, is you should make something people want. And so now I'm happy to take any questions. And I'm Kat Mnialek, I'm a partner at YC. And if you have any questions that I don't have time to get to today, my email is here and you're welcome to email or tweet at me. Thank you so much, Kat. Thanks. So just for the process, we have Slido and you can choose the questions in front of you. If we run out of questions, we have a catch box which we will throw at you if you have a question and we get to it, you can raise your hand. But only after that. Oh, okay. What is the best pitch I've seen and why? There's so many. I'm like cycling through hundreds in my head right now. And so I'm going to tell you a few that just jumped out at me. It might not be the best of all time, but the ones that jump out at me, so Calller, I think about, which is the Fitbit for cows, is one that I loved in an application just because I had so many questions. I didn't realize that was a market. One I saw that also went through YC, called themselves the Palantir for Potatoes. Basically, they were building a tool that helped farmers track all their analytics and data. And one that I love is a company that pivoted. They were originally in YC building a blood pressure monitoring app. And then they, during the batch, they launched something. And their short pitch was, if you text this number, will make anything happen like magic. And they were called magic. And overnight, someone, their friend, they just gave this number to friends and family. And one of their friends posted it on Reddit. One of their friends posted it on Hacker News. And overnight, 40,000 people signed up for their service and started texting that number. And so it was a short pitch. It was clear what they did. It was obviously tapping into something that people really, really wanted. Because overnight, 40,000 people signed up. So that to me, those are sort of the three that randomly occurred to me right now. So what is the future of pitching? So any new tools? So tools in terms of building pitches, I don't have anything for you. But one thing that I will recommend is that YC, when we have companies launch, we a lot of times we'll have them launch on Product Hunt as one of their very first times they're launching to a community online. And Product Hunt, honestly, it's basically a Reddit for products. So every day you can go on producthunt.com and see some of the top products from around the world that are launching. And people upvote the question, or people upvote the products. And you can kind of talk to the founders and do a Q&A. And so they, sometimes the founders will sort of test their pitch out on that community and iterate based on their feedback. And what's interesting is that if you have a product that people can sign up for, if you have something that is self-serve, it converts, Product Hunt has converted better for many of our startups than TechCrunch or like any press. So it's a friendly community. It's a way to sort of test out your messaging on a friendly community of other founders and makers and some investors are in there too. Let's see. So sometimes good speakers are not good pitchers. What's the difference?  And they're compelling presences. But they're not always good pitchers because you have to sometimes, you know, as I said, sometimes they're very ambitious people wanting to solve big problems. Sometimes they ramble. Sometimes they'll go on and on about the particular problem they're solving, especially if they're deeply technical. They'll get into a lot of really deep technical jargon or a lot of folks that we've worked with who are in the hard sciences, biotech. We'll use a lot of very, you know, scientific or technical jargon that the vast majority of the world can't understand. So even if they're compelling speakers, you still have to sort of work on a pitch that anyone can kind of repeat and work with you. Anyone can understand. All right. Cool. Thank you so much. That's it. Thank you so much. Thank you. Thank you. Thank you. This is amazing.


You have most likely heard of the Food Network show Chopped. Well, a similar kitchen showdown is taking place in central Minnesota. Our Sarah Wicklman joins us live from our Brainerd studio with those details. Sarah? Yeah, Josh. It was a pretty exciting night tonight as Sprout and Little Falls hosted their first ever cooking competition known as Minced. Now, it's exactly like the show Chopped with three judges, or three rounds, excuse me, a panel of judges and a mystery box of ingredients that you have to use, all while the clock is ticking down.  My heart kind of sank because one of the ingredients I've never seen or worked with in my life. That was just a tough one. Three local chefs faced off in the ultimate cooking competition. Twenty minutes is really a time crunch to try to really get something to put together. The idea that I had, it came through on the plate.  I should have done that. No, no, no. As thoughts, ideas and creations came to life while designing the perfect plate. You want to look for presentation because that's the first thing you see. If there's an aroma, you want to take that in. You want to use your senses and, you know, make sure that whatever the chef has come up with is in line with what the ingredients are meant to be. By bringing a good balance of flavors from local ingredients. Our region is very rich in our agricultural history and in the growers that feed us. And we just want to bring that narrative to light and have people have the opportunity to play with their food. And have connection with one another. And what better way to bring the community together than through some quality food. Trying to do something for the community to shift the way that people eat in the community to start eating healthier, fresher, you know, breaking the norm here for Minnesota. Even though the cooking tonight was done by the professionals, the community members will take home some recipes of inspiration. Hopefully it'll also bring more people in to cook because we all know the more we cook at home, the more healthy we'll be and the better we'll feel and the more we'll support the local food system, which is what this is all about. Although the night was all about local food, it was also just a lot of fun. And there were three great chefs representing Brainerd, Crosby and St. Cloud. But at the end of the night it was Chef Scotty from the Iron Range eatery in Crosby who took home the Master Chef and the People's Choice Award. Reporting live from the Brainerd studio, Sarah Winkleman, Lakeland News. All right, thank you very much, Sarah. The funds raised at tonight's event will go towards launching the new Sprout mobile market aimed at closing the missing meal gap in rural Minnesota. If you enjoyed this segment of Lakeland News, please consider making a tax-deductible contribution to Lakeland PBS.


What's going on everyone? Sam here with late in sports cards. We are up in 2223 Bowman at University Inception Hobby, 16 box full case break, number nine, random hit style. The way this is going to work is I have our 32 participants copied into the random.org sheet right here. I'll also have a blank one where the hits are going to go as we do the break. Donnie is going to be typing in a description of every hit in our random hit sheet. Once the break is over, all the hits have been shown. They'll be copied back over into the blank random.org window. We'll roll the dice, say it's eight times, random names eight times, hits eight times, whatever hit is next, your name is what you will receive. Good luck here everybody. I'll explain how the numbered cards and the base cards will go as well. Yeah, please do. I kind of know. So those things, I got to see it to understand what's going on. There we go. So as you can see in the top can, empty case, box fell behind. So basically how the box is going to be set up is we'll open it up. There's going to be one numbered card on top, two autos and then four base cards. The numbered card will go with the first auto and the four base cards will go with the second auto. In the event of a redemption, the numbered and the base will go to the non-redemption. The redemption will go by itself. Most of the redemptions are good enough to go by themselves. First auto gets numbered, second auto gets... Yes, so basically it'll be Vincent Iwachuku to 75 on the numbered card. First auto is going to be KJ Jefferson, so that'll go with that one. KJ Jefferson is the first auto. Nice one there. First, or second auto going with the base cards. Jalen Cook, got Jalen Cook. Going with that one as well. Nice one there. And then we've got base. Jalen Wilson, Nick Singleton, Caleb Williams and Jordan Walsh. Oh yeah. You're good. Sorry. Box two. You're good. Next box. We've got Mikey Williams to 199. That'll go with the first auto, which is a gold of Winston Wright, 15 of 50 for Florida State. Congrats and good luck on that one. I think we have two gold autos. The second one will be LJ Cryer for Baylor, 20 of 50 on the gold auto as well. LJ Cryer. Just make sure to do base auto too. What's up? What? Do you think we should be typing in base auto too? Is it a hit? Yeah. For like KJ Jefferson base auto, I'm saying on the random hitch. Oh, I mean, as long as I get the number, I think that's what we should be doing. That's true. Like you said, if there's more than one, we'll do one. Yeah, true. Will Shipley, Jeremy Roach, Sky Clerk and Oscar to Sheetway. Yeah, I guess I could just say like all the non ones that don't have numbers are base autos. That kind of makes sense. Ernest Uday Jr. for Kins. We've got Orange. That is Kate McNamara. Nice one there. 15 of 25 for the Iowa Hawkeyes. I would say just put the, with the numbered stuff, just put the number and what it's number two. So like 25 of 50. Okay. Just to be safe on that one, I would say. I have not gotten Zelda yet actually, Joshua. Nice. Anthony Richardson, 27 of 199. Good luck on that one. That's awesome for Florida. Very nice. I would say you just will nag as one didn't happen to break. Yeah. We've got Will Lettuce. Armando Bacca. Phil Jakovic. Chris Murray. Grab didn't look at what I grabbed. Grabbing things. All right. On to the next one. Yeah, very nice. First Richardson, I fold. Jalen Carter, 2199. Nice one there for Georgia. Now an eagle, right? Jalen Carter. Yeah. Nice. Chris Livingston, base auto for Kentucky. That'll go with the Carter. We've got another gold. This time, Jeremy Roach for Duke. That is 17 of 50 on the gold. Good luck on that one, everybody. Base is Cam Rising, Mark Mitchell, Lauren Betts and Ernest Uday, Jr. All right. We've got Lauren Betts to 299. Nice one here. It's going to be a Bijan Robinson, 85 of 100. Oh my God.  Bijan Robinson to 100. Good luck on that one. Followed right behind it. How about a blue? Will Lettuce, 19 of 99 for Kentucky on the color match. Pretty solid. What a box that was. I would say you could probably will mag the Lettuce. We'll just go through it after and just go through everything. Base, we're going to have Blake Corum, Hunter Dickinson, Jaren Hall and Cameron Ward. Great box right there. Good lord, man. Bijan Robinson again. Wow. Blue auto is going to be a Brandon Murray for Georgetown, 35 of 99. Blue, followed by a Jeff Sims for Nebraska. Nice one there on the base auto. That'll also go with the base here, Spencer Sanders. And there's a Mikey Williams in there as well. All right. Next box. Again, guys, still 20 to go on Bowman Chrome. Not Bowman Chrome. Top Scrum Sapphire Edition. 22, that is. 20 to go. 2022, Top Scrum Sapphire Edition. Gold, Jordan Addison, 11 of 50. There's a Seth Trimble for North Carolina on the base auto. Nice one there, UNC. We've also got a Marvin Mims, 65 of 99 for Oklahoma. Nice base. Bryce Young there. Drew Timmy as well. Jameer Gives. Nice little base pack there. Blue, Tyler Buckner. 299. Base auto is going to be a Al Amir Dawes for Clemson. Nice one followed by a Bonix. That is 91 of 100 on the Inception Auto. Good luck on that one, everybody. Bonix, potential first rounder next year. Base. Brandon Miller in there, and that will do it. Kane Clubnick, 2199 for Clemson. Gold is a Donovan Klingon. Nice one there for Yukon, 13 of 50. He actually, this kid actually played against my high school. Donovan Klingon, yeah. We've got Chris Livingston, 75 of 75 for Kentucky. Bonix, DJ Ugole there. Might honestly. Caitlin Clark base in there as well, everybody. We've got something coming up here, Donny. Got Kim Whitmore to 199. That's going to be a duel of Anthony Richardson and Stetson Bennett, 14 of 25. Wow. Two SEC quarterbacks for Florida and Georgia. Good lord, man, that's awesome. Pretty cool. That's really freaking cool. Again, 14 of 25. It's one off Stetson's jersey number. We'll get that mag after. We've got a gold of Kim Whitmore, 5 of 50 for Villanova. That's a good case so far. Very good case so far. That's really freaking cool, that duel. Nice. Caitlin Clark to 99 on the blue. Good luck to that spot as well as a gold Drew Timmy, 43 of 50. Gonzaga legend, Drew Timmy. As well as an Orange, Mackay, Ashton Langford to 25 for Boston College behind it. And then Walker Howard, Drew Allert, Jackson Dart, and Alaya Boston. Yeah, it's not a bad Clark at all for sure. I would say just make sure to sleeve in top of that Caitlin Clark for sure. We're good. Yeah, we're good. Good point, good point. Derek Lively Jr. to 99. We've got a gold Primordial is Amari Bailey for UCLA, 4 of 50. These gold Primordials pop a lot. Second auto is going to be Josh Wiley, 34 of 50 for Cincinnati on the auto. The base alone is selling for 100 on eBay already. That's insane for Caitlin Clark. A Green Will Anderson. It's going to be gold Jaylen Carter. I saw one there, 29 of 50. Dude, this is a great, this overall I think is the best gates I've opened. Followed by a gold Jeremy Roach, 33 of 50. Nice one there for Duke. Good luck as well. Right here, Donnie. Trace Jackson Davis to 199. Orange Auto is Jermaine Burton, 15 of 25. Nice one there for Alabama. We've got Red Malik Renault, 2 of 5 for Indiana. Good luck on that. Geez, man. This case overall is crazy. Malik Renault. Talia Tagamai Loa. JJ McCarthy, Avery Anderson as well. Orange, Walker Howard to 25. That'll go with a gold auto. Two golds again, dude. Artario Morris for Texas, 47 of 50. Second gold auto, Sean Clifford, 11 of 50 for Penn State. We are, we are. We've got a Marcus Sasser, Julian Phillips, Mark Armstrong, Bijan Robinson as well. All right, guys. Again, we've got 20 spots to go. In Topscrollman, Sapphire, 20 to go. Last box. Good luck, everybody. Watch, there'll be like a redemption of women y'all in here now. Maybe. Like why not at this point, dude? Then no one has to be questioning if this is the best case or no. Right, yeah. Gigi Jackson, 2 of 2.99. We got a golden orange auto. Gold is a Adam Flagler, 38 of 50 for Baylor. Adam Flagler. And orange auto. Cade Clubnick, 19 of 25 for the color match with Clemson. Nice one there. Vincent Iwachuku, Nick Smith, and Holtzmeier. I got to let Donnie type this last one in really quick. Now would be a good time to go and check out Topscrollman, Sapphire, with just 20 spots remaining. All right, let me get those copied in. Thank you, Donnie. Dude, look at all the numbering, bro. We have what? One, two, three, four. Now, one, two, three. There's a lot. Four, five, six. Six base autos out of 32. Everything else is numbered. Pretty good. That's kind of crazy, dude. Good luck, everybody. You're going to roll the dice. We have our hits now copied in. 32, 32 participants. Let's roll our dice. It's going to be eight times one, two, three, four, five, six, seven, eight. Brett W. Down to Alvin S. Eight times on your hits now. One, two, three, four, five, six, seven, eight. KJ Jefferson down to Chris Livingston. All right, we've got Brett W. With the KJ Jefferson. Allen V. Bajon Robinson. Ben C. Bonix to 100. Michael M. With the Jermaine Burton to 25. We got Ben C. Kate Clubnick to 25. Joel M. Brandon Murray to 99. Robert B. Seth Trimble. With the Anthony Richardson RPA. Nice. Tim W. Jeremy Roche to 50. RER with the Will Levist to 99. Congrats, Ari. Anthony J. Kate McNamara to 25. Ben C. Arturio Morris to 50. HPC. L.J. Crier to 50. Sean K. Marvin Mims to 99. Joe P. Josh Wiley to 50. Ronald A. Jalen Carter to 50. Chris C. With the Richardson and Bennett RPA dual. Congrats on that, Chris. Addison M. With the Chris Livingston to 75. Ben C. Jeremy Roche to 50. Addison M. Winston Wright to 50. Manny V. With the Malik Reno to 5. There you go, Manny. John W. Donovan Klingon to 50. Ben C. Mackay Ashton Lankford to 25. And Al Amir Dawes. Got Alvin S. Sean Clifford to 50. Followed by Nicholas S. Jeff Sims. Ben C. With the Drew Timmy to 50. Alexander Samari Bailey to 50. Ben C. Adam Flagler to 50. Joe P. Cam Whitmore to 50. Allen V. With the Jalen Cook and Alvin S. With the Chris Livingston base. Let me get these copied over, guys. Thanks again for the fill. Up next, we have number 10.


ing approaches and how we can really improve the conservation and the sustainable use of our natural resources and our biodiversity to produce more, but produce better and smart, as Ambassador Verde again board, Verde board said. As you see is on the hands of our co-chairs they will summarize what we have discussed today, we'll put together the recommendations coming from the discussion this afternoon, and the summary will be presented tomorrow to our high level panel, where we'll be having Ambassador's United Nations representative, IFI's representatives to take it further. I think is a question where we all together needs to have a holistic approach, we need to move at scale, and we need to find what are the best solution keeping in mind that we don't have one solution. The solutions which needs to be tailored to the different zones to the different regions and to the different perspectives. Thank you again Ambassador Terry Sarge, Ambassador Tenawat for this facilitating, it was a great facilitation, our panelists, all of you I cannot mention you all but thank you for joining us and please keep with us because we have this discussion this afternoon and also tomorrow. Have a nice lunch and see you in the afternoon. Thank you again. Bye. Thank you all our participants also. Thanks. Thank you very much. Bye bye.


What a finish! What a finish! From the substitute. The substitute kick. And here's Broad Excelsior in the future. John T. Johnson with the corner kick. Headed back. And it's a fantastic finish! Into the area. And they're jumping. And they have every reason to rejoice. What a finish from the captain, Chris Taylor. He smacked that one with aggression and passion. Well, as I said to back himself, Damian Stewart would be proud of that kind of finish. And yeah. Oh, lovely play. Brilliant! From Clarenin College. That is straight from the training ground. And it was wonderfully finished. Easily finished too by Kehime Dixon who opens his account now. And here's something to smile about Lenny Hyde. That was beautiful football. And it left Lenny Hyde bang boozled. 3-0 now. But that's what you want as a coach. A coach myself. Is to see what you've worked on on the training ground. Just materialise on the pitch in a competitive game. But that was all one-touch football. From the kickoff. From the dead ball. It was one-touch football. And you don't get it better than that. Chicks in white. Steps up and fires. It swam brilliantly in white with a screamer. It swerved. And it swerved right into the back of that Manchester net. From St. Jiggle with the free kick. This is why maybe we should. And honestly I'm lost for words. And maybe Johnny Gill could describe this goal a bit better. Because my, my, my, my, my, my, my, my, my, my. Water strike. Late Murray. And it's St. Jiggle. One Wolmhurst High School male.


Is it okay to use helpers or safety people when you're doing your exposures or meeting your anxiety challenges? This is episode 220 of The Anxious Truth and we're going to answer that question today. Hello everybody, welcome back to The Anxious Truth. This is the podcast that covers all things anxiety, anxiety disorders and recovery. So if this is the first time you're here and you just found your way to the podcast, welcome. I hope you find the material helpful. If you are a returning listener or if you are on YouTube, welcome back. Always glad that you're here. This is episode 220 of The Anxious Truth. I am Drew Lyncelotta, creator and host of this fine podcast. Today we are going to answer a very often asked question in the community and that is, is it okay for me to use safe people or helpers when I do my exposures? So we'll answer that question. The answer might not be exactly what you think it is, but before we do, quick reminder as always, The Anxious Truth is more than just this podcast episode. There are 200 and somewhat other free podcast episodes as of August 2022. There is a free morning newsletter and podcast called The Anxious Morning. There is tons and tons and tons of free social media content and there are three really good books on anxiety, anxiety disorders and recovery that I have written over the past several years that have literally been read by tens of thousands of people around the world that seem to be very helpful. I'm very proud of them. You can check out all of these resources on my website at TheAnxiousTruth.com. All the goodies are there. Avail yourself of the resources. If you enjoy my work and I'm helping you in some way and you would like to find a way to keep it free of sponsorships or advertising, you can go to TheAnxiousTruth.com slash support where you can find all the ways you can do that. That is never required but always appreciated and no matter how you support this work, whether it's financially or just by tuning in every week, I appreciate you. Thank you very much. So here we are in episode 220. I'm going to tackle this question. Is it okay for me to use safe people or helpers when I do my exposures or meet my anxiety challenges? Can I use safe people to help me get through? So we can answer that. It gets asked all the time. It's a very common question. It's not a problematic question at all. It's something that everybody goes through. Most people go through, I should say. So a couple of things to clarify before we get into the meat and potatoes of the answer and that is, first of all, not everybody in the community has safe people. Some people, when they get in a state of high anxiety or they panic or they're really kind of in that high stress situation, they don't want to be around people. So some of our friends just like to be alone and so therefore they don't have safe people. That happens. But the more common occurrence in the community, not that one is right or wrong, it's okay either way, but the more common occurrence in our community is that people do develop safe people or safety people. So a quick definition. What is a safety person or a safe person?  It could be almost anybody who you place in a position where you think that they are rescuing you, protecting you or saving you from the things that you fear. And the most common manifestation of that is people who because of their anxiety, excuse me, and of course of being afraid of how they feel and what they think, excuse me, will have a ton of restrictions and avoidance in their life. I can't go too far from home. I can't stay home alone. I can't go to parties. I can't go to social situations. I don't do this. I don't these eat those foods or that foods. I don't watch these kind of movies because they trigger me and then I might get anxious or panic or I have intrusive thoughts. And to get around those restrictions because it's really hard to live life completely restricted, we assign certain people those special roles of safety person. So I can or will do those things that I otherwise refuse to do as long as my safe person or safe people, you might have more than one is with me because somehow in my mind, I think that this person helps me get through. They either they calm me down. They make it not so bad. They make it go away. They stop it from happening or if heaven forbid, it really isn't anxiety this time. And it's that thing that I fear that's never true. This person is like the safety valve. Like that person can call for emergency help or bring me to a hospital or whatever it is. So a safe person is a person that you have decided has some sort of special role where they can shield you from anxiety, panic, discomfort and fear. They can make it go away if it happens or they can save you if you literally need saving or rescuing, which I'd like to remind you you never have needed. So that's what a safe person is. And many people in our community do develop relationships with close loved ones or friends, or although it could be anybody where those people become safe people. And then I get asked, is it okay for me to do my exposures or to meet my challenges with the help of my safe person or safe people? And the answer to that is it depends. It depends. So if you at the beginning, if you're in the very beginning of the recovery journey, let's say that you're kind of new to this podcast or maybe you're just reading the anxious truth from my recovery guide. And these are new concepts to you. You've been trying to soothe and calm and ground and control and manage and avoid triggers and none of that is working. And you're running out of ideas. And so you kind of went up here and you discover this guy's crazy. Like he wants me to do scary things. He wants me to intentionally trigger myself. Like these are hard concepts, right? I get it. These are hard concepts to get on board with. And so there may be some resistance. And often there is and that's okay. I totally understand that. But over time, maybe you start to understand, well, I think I'm going to have to try this or this is starting to make sense. I get it. I think I do have to do these things. Yet you are so afraid and you have been avoiding for a very long time that it is unthinkable for you to begin to actually do scary things, right? Maybe take a few tentative steps forward and then you get scared and you run. And you start to think that I know what I want to do these things. This sounds right. I think I want to do this, but I just can't seem to do it. In that situation, if you want to use a helper or safety person to help you get the ball rolling, that would be completely fine. Totally fine. Here we are six minutes into the episode and Drew is telling you that it's okay to use a safe person.  And we can laugh about that a little bit. But that's true. Like in the very beginning, if you have hit, you're trying to overcome that inertia and do the unthinkable that you cannot even imagine that you're capable of doing. If it's a choice between not moving forward and moving forward with the help of a helper or a safety person, move forward. Like use the safety person. That's okay. That is not a crime. It's okay to get started that way. I would never take away something that helps you move forward. I don't care what that something is. If it's a person that you term as a safe person or if it's cold water or ice packs or whatever it happens to be, if that helps you get started, there's nothing wrong with that at all. I would much rather see you get started that way than to not get started at all. It's completely fine. However, if you do get started that way, and this is where the answer starts to morph and go the other direction, understand that you are starting that way. I am using my safe person, my safety person, my helper to get me started. This is really scary for me. I'm not sure that I think I could do this on my own. So I will first use this person in the beginning to help me get the ball rolling because it's far better. Excuse me. It's far better than me just sitting on the sofa continuously. So I'll use this person to help me get started. But I know that at some point sooner rather than later, I'm going to have to leave the safe person behind and start to do these scary things alone. This is where we go to the second half of the answer. Oftentimes, when you query somebody who has built what I always like to call the acceptable bubble or is in the state of what they might call a relapse or a setback, you might find that one of the hallmarks or one of the leading indicators that a setback or a relapse can happen or that there is an acceptable bubble and they cannot seem to go beyond that is the presence of a safe person. Not so much the presence, but the use, the continued use of a safe person. So I'm not trying to call anybody out here because we all do the best we can and we can cheer for each other while we do that. But I cannot tell you the number of people that I am aware of today in this community that are making progress that they should and are should be and are proud of. And I would not take that away. I'm proud of them too. But when you dig a little bit, you see like, Oh, all the things that they're doing that they used to refuse to do that they've been doing now for three, four, five months, they're still only doing with somebody with them. I have two friends that helped me or it's always my partner or my sister or my mother or whatever. It doesn't matter who it is. It could be anybody. It doesn't matter who it is. And you discover that there's still a safe person in the mix. So look at me. I'm doing great, which you are, but I'm still doing great under a condition. And that condition is I have to have my safe person with me. So full unconditional recovery that is most durable and least susceptible to breakage relapse setback comes when we leave the safety devices, including human beings behind. That's hard. That's really hard. So we can use those things to get the ball rolling. But sooner or later, we have to leave them behind. Why do we have to do that? And why if we refuse to do that and we accept this sort of conditional recovery, why is it? Why do we remain susceptible to setback relapse, whatever it happens to be? Why is that recovery more fragile and a little less not less durable, less full? It's an incomplete recovery because we never actually learned the lesson that we are the ones that are always capable. Right. So maybe you start off by thinking, I am completely incapable of even getting off the sofa.  I know I can do that. I know I could take the kids to school. I know I can drive about a half hour from home. I know that I can work a three hour shift. But beyond that, nope, I still need my helpers. Right. So you've learned that you're capable of doing things you used to not think that you were capable of, but then you stop and you draw a line and say, but beyond this, I'm still incapable and I do actually need them. So if you allow that to stand and you decide that there are things that are too much where you need that person to be protective or shield or fixer or a rescuer, then you never fully learn that you have always been fully responsible for getting through all the crappy panic attacks and anxiety spikes. You always. The hard truth of this is that as much as they may love us, our safe people do nothing. In fact, if you sat down with your safe person or people tonight and had a quick conversation and said, can you tell me how you save me when I have a panic attack? Or can you tell me how you save me when I spiral out of control? That person would probably have a hard time explaining how they actually save you. And they might say, we don't. There's a really good chance that they may tell you, I don't save you. I just sit next to you.   Like they would have a hard time finding a thing that they actually do because they don't actually do anything. They would be happy to if there was something to do. The people who love us would gladly save us if we needed saving, but they know we don't. So they just sort of sit with us. And that leads me to the difference between support and rescue. It's okay to want support. Like there's nothing wrong with that. We want our loved ones to cheer for us. We want them to comfort us. We want them to understand our struggle. I get all that. That's perfectly okay. But we start to run on the rocks. You know, we sort of run aground when we forget that there's a difference between wanting support and wanting to be rescued or protected. So we would hope that our loved ones would protect us against dangers in the world. We would hope. That's okay. But we are mistaken in our assessment of danger here. Like your own body is not a danger to you. Your thoughts are not dangers to you. So therefore you don't need your safe people to protect you against them or save you from them. And they never have because it's never been required and there's nothing they can do to do it anyway. So if we don't leave our safe people and our helpers behind, we never learn that lesson. We never fully embrace. And that is a cold reality. I get that because on an emotional level, it seems to devalue these relationships. It doesn't at all. Even when you learn that your romantic partner has never saved you and never can doesn't mean that they're any less than in your life. They still love you. They're still support there.  When you learn that and fully embrace that, which we can only do when we leave those people behind and take them out of this process, I wouldn't say leave them behind because it sounds like I'm telling you to cut them out of your life. I'm not saying that. Just take them out of the process of being a rescue you rescuer for you.  And then you realize, I can do this all on my own. Guess what? I always have. And so right now, there was a time when I would have told you, yeah, I'm doing 90% of my life, but I don't know. I got to drive into New York City. I haven't done that in a long time. I should have somebody with me. I would have been wrong, but I would have told you that and I would have wanted to bring somebody with me. Only when I did it without people being with me that I learned, I didn't need that. And I knew it already at that point. But if I had caved and said, Nope, I'm going to have to bring somebody with me. I would have never learned that. Never. So when you ask me, how can you just sit still and just let panic happen and not care? That's how that's how I'm 100% completely sure and confident of the fact that I can handle whatever my body and mind throws at me. I always can. There's nothing that my body and mind can do to me that I will not be able to handle. You know how I know that because I did it alone. And if I had refused to do it alone, I would never have learned that I would never have reached that conclusion. So there would always be that lurking too muchness on the horizon that could come and get me anytime. And life is challenging. Life will throw stuff at us. There will be challenges. There will be stress. There will be sadness and loss and heartache and anger and disappointment and big tumultuous events. All of those things, all of those things, life is a challenging thing. You have we have to learn that we can handle whatever happens. We may want help and support with life's challenges, but we do not need to be rescued from ourselves. It is so important to accept that to be true and then go and learn that lesson to the best of your ability by ultimately doing these things on your own. That sounds harsh, but that is truth. That is truth. And the difference between the person who says I'm completely recovered and could not be less interested if I whether I have a panic attack or not, which we are out here. I'm one of them. I've been talking to you behind this microphone now for eight years. I am one of them. There are many of us. That's one of the key ways that we got here to this place that you think is unimaginable. So just a quick wrap up. It's okay to have support. Support is fine, but do not confuse support with rescuing because you do not need to be rescued from yourself. If you want to use a safe person or a helper to help you get started or to get through a real big sticking point because you have some inertia, you can't overcome. That's never a problem. Just go into it knowing that this is temporary. I'm going to have to leave them behind and that sooner or later, you can no longer use safety people and helpers in your exposures or when you have to do something challenging, you got to learn to meet the challenges yourself. There's your answer. Is it okay to use safe people and helpers during exposures and during challenging times depends how far along are you in the process and what are you trying to accomplish and what do you want to learn? What does having a safe person teach you? What does leaving the safe person behind teach you that second one there? There's some secret sauce there, so aim for that. All right, so not too bad. 17 minutes, answered the question, filled in some details, added more stuff you maybe didn't need me to say. I don't know. Hopefully, I've helped you understand what a safe person is, how we get to the point, we rely on them. The roles they can play and maybe shouldn't play in our lives. I'm going to have to say it again before I wrap up. I'm never minimizing the role of those people. The people we love and the people who love us, they are important. I'm not minimizing your relationship with your partner. I'm not minimizing your relationship with your siblings or your parents or your friends. We just don't want to cement them into roles as rescuers. I did not need my family or my friends to rescue me from me, that I had to learn that. But guess what? Even though I know that and I don't need them, they're still my family and my friends and I still love them and they're still just as important as they always have been. So there you go. That is Episode 220 in the books. A common question, hopefully answered to your satisfaction. Hopefully, hope I did a good job with that. You know the episode is over because music. That song is called Afterglow and it's written by my friend Ben Drake. It was partially inspired by this podcast. If you want to know more about Ben and his music, you can find him at bendrickmusic.com. I always send you over there. If you are listening to this podcast on iTunes, Apple Podcasts, Spotify, any platform that lets you leave a rating or a review, maybe take a second and give me a five star rating if you dig the podcast. If you really dig it, take an extra minute or two and write a quick review because that really helps other people find the podcast. That's why I do this, try and help as many people as I can. And of course, if you're watching on YouTube or listening on YouTube, subscribe to the channel, hit the notification button so you know when I upload, leave a comment, like the video, share it with a friend. Those things all help me out. I will be back next week. I do not know what I will be talking about, but I will be here and remember, as always, this is the way.


The Taj Mahal is the most famous example of Mughal architecture and it is visited by up to 8 million people every year. It is considered by many to be a new wonder of the world and for good reason everything from the white ivory marble to the intricate calligraphy tells the visitor that it is nothing short of a piece of art. To begin with it was commissioned by the Mughal emperor Shah Jahan who ordered it built in 1632 a year after his wife Mumtaz Mahal had died. So it's quite clearly a symbolic commemoration of her death which is said to have grieved the Mughal emperor deeply. Under the instruction of Ustad Ahmad Lohari who was the chief architect it is said that more than 20,000 workers from across India, Persia, the Ottoman Empire and even Europe were employed to construct the Taj Mahal for a period of 22 years. This included calligraphers and 1,000 elephants had to be used to carry materials and of course no self-respecting piece of Islamic architecture could be complete without gardens so plenty of horticulturalists were employed as well. Considering the Taj Mahal was built to remember Mumtaz Mahal people have taken that and ran with it and stretched the truth to fit romantic ideas. One of which talks about Shah Jahan's desire to keep the Muslim a unique masterpiece. In order to ensure this it is said that he cut the hands and gouge the eyes of all the artisans that were involved in constructing the Taj Mahal just so he could ensure that another one would not be built like it. Obviously this makes for a very cool story but there is no evidence to suggest that this actually took place. On the contrary historians have found Shah Jahan to have been far more ruthless than he was romantic.  The extravagant attempt to build something perfect architecturally speaking in terms of its symmetry can be regarded as a source of propaganda that would be fit a man who named himself Shah Jahan meaning king of the world. As you can see in that picture he is standing on top of the globe in order to denote his ascendancy over everybody else. But whilst cheesy myths are not well rooted in the truth the Taj Mahal still has a bag of tricks that will leave you in awe and amazement. For example the four surrounding minarets look like they are upright from far away but they actually lean outward. As well as being a cool trick of the eye this would ensure that the minarets would crumble away from the main tomb in case of an earthquake which was a real architectural consideration in this period. The architect's mastery of proportion doesn't end here. From the main gate the Taj Mahal looks close and large but the nearer you get the smaller it becomes. You think that's impressive? Check this out the Taj Mahal is like a chameleon it can change its colors well at least a hue of the color thanks largely to the sun it can appear orange bronze when the sun sets blue at night and pink and gray during sunrise. The famous poet Rabindranath Tagore called the Taj Mahal a tear suspended on the cheek of time. As a fan of architecture I can't help but appreciate the symmetrical beauty of this timeless monument.


It's increasingly important to show the impact of your research through measures like numbers of citations and H-index scores. A feature of Google Scholar called My Profile makes this easy. You can create a research profile that lists your publications and shows your citations and H-index score all on one page that updates automatically. In this video I'll show you how to create this profile. First you'll need to sign in to Google Scholar. If you don't have a Google account you'll need to create one. Then click on My Profile. Fill in your name, title and affiliation, your Laurier email and your areas of research interest then click on Next. Google will show you a number of publications they think might be yours. If these are correct check the boxes next to each group and then click on the arrow for the next step. Decide whether you'd like Google to update your profile automatically when it detects you've published a new article or whether you'd like to confirm first before it updates your profile. Also decide whether you want your profile public so others can see it or not. Here's what your profile page looks like. There's information about you at the top. You can add a photo or click on the pencil icon to edit or add information about yourself. Your publications are listed below with the number of citations for each. You can click on the cited by number to see which works have cited you. If any articles are missing you can add them by clicking the three dots above the publications list. Then choosing Add article manually. To delete an article check the box next to it then click Delete. Or to merge duplicate records check the box next to all the duplicates and then click Merge. Once your profile is correct look at the cited by box which gives you your total citations H index and I-10 index. These measures are often used as an indication of research impact. You can see your profile by clicking on my profile anytime you're on the Google Scholar main page. If you've made your profile public you can send people the URL for your profile page or they can find it by searching for your name in Google Scholar. If you have any questions ask us at library.wlu.ca. Help.ask us.