We're from Seakeek. Thank you for the intro. And we are here to talk about scaling payments with your growing business. So we are going to just talk about ourselves and what we've done for the next 20 minutes or so. It's a pretty interesting ride and we think that... So first, some quick introductions. My name is Nicole. I'm the director of the payments and risk team at Seakeek. I have worked here for about two years. Prior to that, I worked at Etsy for five years doing payments there as well. My name is Bebev. I go by V, so that's fine. I joined Seakeek towards the end of 2014, early 2015. And I now lead the engineering team that takes care of all payments and risk to Seakeek. Cool. We'll do a quick plug for Seakeek. We have an app. We have a website. You can buy tickets to live events. And we've been around since about 2010. Nine, technically, but let's go with 10. All right. So why do we want to do this talk? Since you're all working in payments or around payments, everyone knows that the opportunities and challenges that you face when you accept your first order are very different from the challenges and opportunities that you have when you're accepting your millionth order. So we wanted to just take you for a little ride about what was interesting in our journey doing this and some scary and cool things that happened. From an engineering perspective, you accept that there's going to be challenges. There's going to be scalability and servers and AWS and all the other stuff that we all work with. But Justin set this up pretty well for us.  You might have the best standards, but you can't enforce them. You have to be very flexible in how you process payments. Just like a 10,000 ticket, if you just go and buy 10,000 tickets for one, it's very easy to have a nice chase on API. But then when you need those Broadway tickets, you're working with the XML and XML and XML partners as well. So having a flexible partner that allows us to do a lot of this stuff is how we've been able to do it. So that's what we're going to talk about. So we're going to talk about this now as we journey through the business models that we've worked with over time. We started as a search engine. Then we moved to a native checkout experience still sending the payment to our partners. Then we became merchant of record for transactions. We built a marketplace to accept inventory from consumers and smaller professional ticket sellers. And most recently, we've gotten into enterprise. So let me take you through this journey as we saw it. So when we were a search engine, we dealt in this idea of clicks. What was important to us was this idea of building a kick-ass interface, running our scrapers at night, going out there, getting all the events that were on the internet, getting all the tickets for them with permission from our partners. We were not creating people without their permission. Well, in some cases, we might have been. But we were essentially getting every event, every ticket we could find on the internet and putting them on Seed Geek with a kick-ass UI, assuming that our partners that actually sell these tickets will be able to handle the checkout process of this. So this is what it looked like. We had this nice map that we built. This is a recent speech on this map, a vector map style, you can zoom in, zoom out, whatever you want. We developed this idea of these numbers that we see, which is deal quality, where we look at six or seven years of data about transactions and how they work. What I'm going to detail is one of the interview questions we asked, how do you sell my tickets? I'm going to tell you a lot. We had nice, great amount of tickets, and this blue button. And when somebody clicked on that blue button, that was a click. And that's how we were going to get paid. Get people to click on that button, go to a partner website, have them do checkout, and we'll be fine. And then that's when we started realizing that, well, it's not that easy because. People aren't checking out. They get to the partner website, and that's a speech of 2018, yesterday. So I just want to make sure that this is not 2030, this is 2018. And a lot of times, people were sort of ending up with these checkout forms, and just had to go through six different steps to do this. None of the information was going to be saved. We could do this every time they wanted to get from us. On the left, that is a mobile checkout form that we come on. And it was just like looking at that on your iPhone screen wasn't ideal. If this is 2018, five years ago, things were not this good. Nothing was going to go along the lines. And around 2013, 2014, we started noticing this trend where a lot of traffic that we were getting was immobile. So we got our Android app, we got our native iOS app. And we were having people sort of do all the map stuff or selection to get everything on native apps. And then with the click, the thing that was so holy to us, we were just sending them over to a website like that. We just wasn't working. So that's, yeah, so we decided to build native checkout. And why did we want to do this? Like I said, beginning companies were not doing mobile well. It was just not a thing that people were able to do. And this great checkout experience that we'd built of this great idea of how you look for tickets, how you select things on a map, how you do deal quality, none of that was worth it if you're not going to make any money in the end because people just weren't checking out. It was obvious that we needed to build native checkout on SeatGeek, but then we were thinking about, wait, we're a very small company. We don't even have a lot of engineers. And this is around, we had like maybe five engineers at this point, so we were thinking about, wait, how do we even get payment information securely to our partners? Some of these guys were PCI compliant. They were like, send us a 16-digit bin, send us your CVV, and we'll take care of this. And then other partners were telling us, well, we are not PCI compliant. We use this payment service provider, whether it's BrainTree or Stripe, or something. One of them was actually a Swedish customer.  So vault our credentials, just give us the token, and we'll do the rest. And one of the issues that we were also having was, this is how fragmented the marketplace was. So each one of those colors is one of our partners doing that percentage of transactions. So we couldn't have just picked one partner. We were like, OK, we'll go with how these guys do it, and we'll just enforce. We had no power to enforce any. We still don't, in a way. But we couldn't have just picked one thing, and we were sort of thinking about this whole idea of, how do we even do this? Which is when we wrote this email to Spreedly. I'm actually going to try to read this. It's very interesting. It says, hey, Spreedly, I'm writing from a company called SeedGeek. We're considering a new feature with some complex vaulting needs. And by complex, I mean potentially impossible. Based on some looking around, it seems that you guys are the expert when it comes to this sort of thing. So I figured if you would help. So this is an email that was written in 2013. I think there was some back and forth for about eight months, and it wasn't like we didn't have a solution still. So we were kind of just building the still, the amazing apps, and sort of going through designs. But we just didn't have native checkout until someone who started us and said, hey, you can now use Spreedly as this proxy, and you can sort of deliver these payment methods into your partner. We were like, yes, let's do this. So here's just a few samples that I pulled out. Someone, I think you all was talking about X and L, and X and L, but is there X and L, and X and L? Right over there. You guys can see this part. There were some APIs that were just nice. There were JSON that we could just easily put our little mustache variables in and just deliver information to them, and it just worked. And people would reach out to us, and everything was fine. And then you had the legacy, the Broadway partners, as you call them, that had these old SOAP APIs where we had to escape XML inside XML. Sometimes there was another layer of XMLs. So just to share, these were some of the good partners, honestly. The people that had SOAP or had a WSDL, these were people that I liked working with. There were other API partners where there was no response. The response used to be a URL, and you had to keep polling the URL for a zip file, and then open the zip file, and then that's where the text file with the response was. So it's like one of the things that you'll notice is as you get closer to the source of the tickets in the ticketing industry, that level of technology actually goes down. It doesn't go up. Anyway, so we were able to use freely as a proxy, and that led us to be able to build a native checkout experience in SeedGeek, where a SeedGeek user never had to leave SeedGeek. They could buy their tickets, and tickets, unlike a lot of the other sort of commercey things, is something that you can buy on a phone and then use it on a phone. So we built this idea of just mobile entry. So you could literally buy your tickets on a phone and just scan your tickets in. And I've used that feature so many times as a Nix fan because tickets are really expensive. So what I would do is just wait till the last minute when all the sellers would drop their prices, because no one was going to go buy a ticket and go print it out. So I would just stand outside Madison Square Garden for a while, buy a ticket with five minutes left, or sometimes after the game started, and just sit in one of the seats for $10. Anyway, that was a big win for us. So the next step in our evolution was becoming merchant of record ourselves. So all this work that the team had put into building native checkout, we were still sending the payment credentials out to third parties. And so the rest of the transaction that a customer was experiencing, the end of that was with somebody else. So if they had problems, if they had issues, they couldn't tell us. We would have to redirect them. And that just wasn't a great experience for them. So we knew our customers better than anyone else. So we figured, let's keep them inside our system for that entire lifecycle of the transaction. We wanted to do that. We knew we wanted to have more control. We knew that would be a better experience. And if we were charging the cards ourselves, it meant that we would be able to get to work with some of the more professional sellers that existed in the ecosystem so we could get better inventory. We also wanted to have better pricing. So if we're negotiating a wholesale rate for tickets from the source of those tickets, that means that we can do things like dynamically price tickets because we know the event is popular or it's close to the start time or whatever is happening in the market. We get to decide how much we want to sell that for. And we wanted to have more ways for customers to pay. This was back in 2013, 2014. Apple Pay had recently launched. And we wanted to be on the forefront of adopting these new technologies. And we just couldn't do that if we were still relying on third parties to process payment. So all we needed was a merchant account, right? So we went to a web form, sort of like this. Didn't really look at any of the bells and whistles. Just sort of knew what we needed, signed up, and we were on our way. Dollar signs. Anyway, once that easy part was done, some of the other people that worked at CT had to look into how this would actually be done. So one of the cool things that we already were seeing, we didn't understand what a speed leak gateway was. I have to admit at that point. All we knew was we have these receivers. And I was looking at the Braintree API integration and all that stuff. And I stumbled upon this idea of speed leak as a gateway. And I was like, wait, they already did all the work for us. This could literally be the last API that we ever work with. That's exactly what I'm saying. So we were already, because we were delivering information to our partners securely through speedly, the receiver delivered product, as we all call it that now. We realized that, oh, wait, all of our banking payment methods are already in abort. So all we really have to do is deliver them now to a gateway, and then everything would just work. So as Nicole talked about building the merchant of record experience was so much more than simply charging credit cards, we were able to actually spend more time doing those things. And the speedly integration kind of just worked out of the box. We didn't have to do much there. So we were already calling. I think we were already vaulting things. All we had to do was start authorizing cards through speedly, calling the settle method on speedly, in some cases having a void or a refund. But everything was essentially going through speedly. And we were like, wow, this is awesome. We don't have to worry about this at all. And then Apple Pay was, I think we worked with speedly, if I remember correctly, when we were doing Apple Pay. It was a complex process of uploading a certificate. But once you were done with all of that stuff, Apple Pay suddenly started working. I remember that day when it started working, it was like, there is no way this was this little work. This is not working. There's no way this is working. Android Pay was a little more work, but we eventually got to that point. And during the whole process, there was a lot of very productive back and forth with speedly and, you know, speedly with Google, and then Google Seed Geek. There was a lot of back and forth, but eventually we were able to support all of these payment methods that we were hoping to be able to store. Yeah, so it was working. We put in the work, and we saw the transactions coming in. Everything was going smooth. We thought we were good. Is the clicker gone? The clicker is good. OK. So we knew we were officially now in charge of customer service, refunds, chargebacks, anything risky that happened on the platform. As I mentioned, customers were already reaching out to us, and we had to redirect them. So we didn't want to have to do that. We had this nice web form where people could talk to us, send us their questions, and then we also had to worry about fraud. We were slightly less prepared for this one. So we knew it was a thing. We knew what chargebacks were and knew about fraud in a general sense, but weren't totally prepared for what we needed to do to mitigate it. So this was our chargeback slide. The red dotted line was the arbitrary goal that we had set for ourselves to say, this is what we think the limit should be. And for the first several months, everything was within the bounds that we were expecting. And then all of a sudden, out of the blue, we had that happen.  So we sort of had to scramble. And this was around the time that I joined the team as well. So we brought it back down. Don't worry, we're safe now. But there was a lot of stuff that we had to do internally. We had developed some internal tools that we're still using today, one of which is an order review queue system where we have some rules around what transactions we can review, which ones we want to accept, which ones we want to reject outright. We have some external partners that we're working with on the fraud side that are really good in this space. We set up those integrations. We pulled together a new team. So this was when the payments and risk team sort of started. And we have people that are reviewing transactions every day now, looking for risks in the marketplace and keeping everyone safe. And there was a lot of shared learning happening during this time. This was definitely a crash course in risk for Piki. Very exciting. I like how I'm laughing now. So we did all of this. We had a platform that people could do native checkout on. We could charge credit cards. Everything was going well. But like any other company with BC money, we had to grow. We had to find other ways to get bigger, drive more volume, get more customers. And this is when we really started digging into our data and try to figure out, how do we do against our competitors when it comes to tickets? And this was like a study that we did. And we figured out that because we had this merchant record stuff, we were doing dynamic pricing.  Every time we did have tickets to a certain event or in a certain section, a certain row of a stadium, we had the best prices. But we didn't have all the tickets. So that was an issue. So our competition is like 20 times our size at times. So you know, companies that sell a lot of tickets. And just doing this analysis, we realized there were two things that we had to do. We had to build a marketplace, which not only caters to Seeky customers, but if you bought a ticket on Seeky, you should be able to sell it very easily, but also to professional sellers that have contracts with major teams that make wholesale deals with them and just get like 15,000 tickets to every Dallas Cowboys game or something like that. And we had to bring them on to our platform. And like I said before, as you get closer to the source of tickets in the industry, the level of technology drops. So this meant that we had to build a lot of tools for them. And one of the reasons we were able to spend a lot of time doing that and building cool UI interfaces like those, when our competition at the time would make you search for an event, then enter the name of your section, enter the name of your row, enter the ticket quantity, and then ask you to come up with a price. We just had someone drag a PDF that would be instantly parsed, and we would suggest a price based on our deal 14 saying, hey, you should sell this ticket for this price. So we were able to do a lot of that and build all the tools our professional sellers needed because the payments piece of this just worked out of the box. So in Braintree, we had a marketplace product. And Spreedley did a pretty good job of sort of exposing the custom variables that we needed to pass during an authorization request that will allow us to split payments between the marketplace and the merchant. So that's essentially all we needed. So again, we found ourselves in this place where we were like, wait, we thought this was going to be a lot of work for payments. Turns out it's not. So let's just build a better marketplace, which we were able to do. Because we are a customer facing company, it doesn't like a lot of logistics don't really matter. People just want the easiest way to list their tickets and being able to just have this luxury of just putting in a lot of work on the marketplace product itself and not worrying too much about payments was another sort of major win for us. Things are still going well. We are growing very quickly at this time. And this is me and myself climbing up Transaction Mountain, dodging boulders left and right. So another interesting thing that happened when we sort of built this marketplace was we started talking to these sellers. And we honestly, at this point, we were like, well, we're definitely at parity with our biggest competition. And everything's good. I don't think there's a lot of work left. And that's when we sort of stumbled into this whole idea of what are the issues that the sellers are facing. So we've always been a very customer focused company. But now we have this other side of the marketplace where people are just trying to sell their tickets. And they're essentially small businesses. The professional sellers, at least, are just basically small businesses. And they have their own challenges. So some of the things that were obvious to us is that you could own your tickets. But there was no real way to export them into a format that you could list tickets on any other websites for. There was no central place to be able to do that. This whole idea that a ticket is a piece of paper that you have, like a hard ticket, as we call it, that idea was going away. Everything was sort of mobile entry and people were doing those things. PDF was still a concept. But it was definitely going away.  Are you just buying a PDF? It's so easy to lose. It's so easy to be stolen. It's like, I don't really understand this whole idea of PDF, but it did make things very convenient when it came to reselling things. But now that idea of PDF was also going away. And then the sheer number of the long tail of event delivery methods that we just were not able to handle because we had no control over this was mind boggling. So we had to be able to sell will call tickets, VIP tickets, meet and greet tickets, Rihanna backstage passes. It was, there was just too much. The industry was extremely fragmented. And that's when we decided to sort of put some focus into saying, you know what, we are doing this well, but let's try to study the industry and see what is there a dent that we can make in the industry? Can we change how these things are looked at? So this sort of introduced us to a lot of the challenges. It just existed in the ticketing ecosystem in general. So we had solved a lot on the customer facing side. We were starting to solve a lot of things on the ticket seller side when we were servicing our platform, but there was still just a lot in general that we couldn't do anything about. So ticketing, if you're not aware, it's a really closed ecosystem. The ticketing companies that are out there in the space are controlling where people can sell tickets, where people can buy tickets, and the people that are organizing events, the teams, the venues, the promoters. They have a really hard time dealing with this because they have to work in such a narrow framework that is built by someone else and controlled by somebody else. There's also a big issue with data. If you can imagine, the ticketing companies do not want people to resell tickets. They want them to use them themselves. So what that means is that if you need to sell your tickets, or if you want to sell your tickets, whoever is showing up and sitting in your seat, that person's name is not on the ticket, that means that the team or the venue or the promoter has no idea who's actually attending their events, and it's a huge missed opportunity for them, for marketing, and for any other purposes that they have. And like Vee was talking about, as you get closer to the source, the technology levels just drop completely. These are all legacy systems, and the customers that are using them are huge, huge, $100 million teams, venues, organizations that have a lot of prestige in the industry and they're stuck using these crappy things. So we thought maybe there's something that we can do about this. So this brings us to our most recent model that we've been having to work in, and that is Enterprise. We are now a partially B2B company, which was a new thing for SeatGeek as well. And so how did we do that? We went out and we acquired a company. TopTix was a ticketing software company that was active in the United States, very active in Europe, Australia, kind of all over the globe, and now they are a part of SeatGeek. This has been really exciting for us, but sort of what was being referred to in the last presentation, when you acquire a company, you might be acquiring another legacy system. So not only did that happen, but we now had a lot of new things that we, we knew we were gonna have to support that we've never had to think about before. So how do people pay in a box office? With a device, with a device, it probably has to be EMV compliant, could be different requirements based on the country. We now have deposits. A lot of teams want to have their customers be able to pay for a part of the payment for whatever they're purchasing. We have season tickets, so someone's gonna pay a huge lump sum payment for like a bunch of inventory, for a bunch of different dates, and we need to support that. And last but not least, on sales, we're a huge challenge for us in terms of scalability. We need to be able to process thousands of transactions in minutes, which is just something that we never had to worry about previously, and obviously there's a lot riding on us getting that right. So the company that we had just acquired, TopTix, we thought maybe they had solved this. Maybe they were doing something that we can just learn from and carry that over into C-Geek Enterprise. And so when we reached out to the engineering leads in that team, we asked them, who did you integrate with for payments? Like, who were you working with? What worked well? What didn't work well? How did the clients tell us what was going on there? And the answer that we got was, well, we would just integrate whatever the client said they wanted. So we said, well, how did the client know what they wanted? So a lot of clients had the same requirements, but weren't talking to each other and the company wasn't really recommending anyone in particular. So what happened was there was like 50 plus payment integrations, a bunch of which we had never heard of, that would be activated and integrated for one client, and then an engineer would never look at it again. So there was bugs, there was issues, there was tickets getting opened all the time because some minor thing had to be fixed with an integration. So it was an all around not great experience and we thought that maybe we can consolidate some of this. Maybe there's some similarities in some of what clients are looking for. Maybe there are partners out there that can help us solve like 80% of the use cases and then if we need to add more, we can add more because we know that it would be easy to do. So we went out and did an RFP for a new partner and many of you probably know what an RFP is. I did put the technical definition here because it sounds very professional, but when we were doing it, it sort of just felt like, oh my God, how do we solve this really quickly? What are we gonna do? So this was a really good example of like in the past when we just went to the web form, hey, we need a merchant account for US e-commerce, US dollar transactions, that didn't work anymore. Now we have devices, we have countries, we have currencies, weird payment methods, and we need to be able to support all of it. So one of the themes that you might have noticed in the whole presentation, we were always running out of time, like always trying to catch up with a lot of this stuff. And I remember the RFP process where we were looking at a bunch of, I think there were three or four, I think it started with a bigger list, but then we were down to the final three or four. And one of the really cool things about that whole process was that we didn't actually have to look at their APIs. Like, I know that was a concern that some people in the company had, like do they have good APIs, but in my head, I was like, I hope Speedly's doing this, like I'm not actually gonna go and do stuff with their API. So I was very happy to see that the one that we chose, in fact, the last three that we were on, like all three of them were supported by Speedly. So I was pretty ambivalent from an engineering side, like whatever you pick, I'm cool with it. And, but then we did have to re-engineer our payment service. So this idea that we had one payment provider that was gonna do our marketplace, it was gonna do our box office stuff, it was gonna do everything for us, that idea basically completely broke down. And we were in this partnership, we had, we were the official ticketing partners of the MLS, which is the major league of soccer. And we had signed the Sporting Kansas City as our first team and signed two more teams that we are ticketing this season. And we needed these solutions quickly. So, we, Slack, we use Slack. So there was a, there was a, we had to really build this quickly. And then we sort of modeled our payment service based on the fact that, you know, Speedly allows you to have multiple gateways. So maybe we can modify service to invest heavily early on in the transaction when you decide which gateway to use. So look at a transaction, look at the users that's making the transaction, look at the IP address of the person that's making the transaction. How can we make this extremely genetic where payment processors, instead of like being integrations and code, just become data. There's a list of integrations that are all represented by this one string that, you know, it's a gateway token that Speedly gives us. And all we have to do, like my coding problem was simply given a bunch of attributes about this transaction and this person pick the best string. And that's it. So if we think about adding more payment processors after all the work that we did, it's basically no work. It's just adding another thing to a data structure and then figuring out what attributes that maps do best and then just picking it for the transaction that's happening. So on the right, there's a slight graph of, and you'll see a lot of these dates that we're going through a lot of this transition right now. And we are sort of very easy to, it's very easy for us to like drag a slider now in one of our admin tools and it just sends transactions one way or another when we have to. One of the things that Nicole talked about which is challenging for us was this idea of an on sale.  Those tickets are going to sell in 10 minutes. There's going to be 100,000 tickets sold in 10 minutes. And I remember I think it was either Luke or Nathaniel, they were at the Seed Geek office and they were selling us that you should realize that at that level of transactions the payment processor is going to slow down. It's not going to be Speedly or Seed Geek. So you have to be prepared for those things. Because of this fact that Speedly takes out all of this coding integration stuff and converts that to data, we now have an effective payment service that can just choose and pick whichever payment service gateway that we want to go to. And we were like, yes, we can now rest. Everything's good, everything's working. I'll go take a vacation, Nicole can hang out with her kid and then this happened. So Cowboys, for those of you who don't know or don't follow football, are the biggest sports team in the world. I Googled this, I did Google this. They are the biggest sports team in the world, not in the US, not the biggest football. They are just the biggest sports team in the world. So this wasn't supposed to happen. There's no way this can happen, but it did happen. So this started another mad dash. It was like, oh, I thought we were done. And then, well, then let Nicole talk through the rest stuff. Yeah, so that happened. I think we had about six weeks to get it up and running, not only to make sure that all the payment stuff was ready to go, but that the software that we had, that they were gonna be using, essentially as their entire ticket manifest was up and running and integrated and installed. So this is us on the right. This is in, to the right of this is a wall. And then on the other side is the window where people walk up and buy tickets at the box office. So we're in the box office with the devices that we're installing so that they can accept payments in their box office. And this is just a nice picture of AT&T Stadium. It was before a soccer game that we got to attend while we were down there visiting. And it was just a completely surreal experience and kind of brought together all of the years of hard work that we had done on the like scaling payments. Like, oh my God, how do we do this side? And it is working, so. So again, from the engineering perspective when we were sort of given this news that, oh, you've signed the, besides the fact that I'm a Giants fan. I didn't like it. I'm a Giants fan too, so. It was also a little disappointing in the sense that, wait, so what do we have to do now? How does this affect our payment service or our NUDE sort of created this? Couple of things were easy. So if they wanted, if the Cowboys wanted to use a different payment provider, we could just add that as another gateway to that list that I talked about. So the other challenge here was that for all the good things that our back-end primary system does, the UI for everything, the customer interaction is still CPEAK4, right? So we had a bunch of payment methods that were in CPEAK that needed to make its way back to our back-end sort of primary technique system so that people could be charged for season tickets through subscriptions, et cetera, where someone's sitting in the box office. So the idea is there's a credit card that lives inside CPEAK.com that somebody bought an MLB ticket. Now I need to make that credit card go from there all the way into our box office software so that when they call to renew their season tickets possibly for the Dallas Cowboys, the rep sitting there can simply click a button and they just do this. And the interesting thing here is that there's a gateway store method that allows you to store tokens which did not exist for this payment provider that Dallas Cowboys. And I think it was done just in time. I think it was delivered the week before by Spreadly. So thank you, Spreadly, for doing that. Listen, you said this is the last payments API so I didn't want to do it myself. That's all I'm saying. So they were able to deliver that method just in time and then we were able to sort of launch the Cowboys. So the future, the future, that long arrow, I thought we were going to fix that. Anyway, so the future is very exciting. Based on what we've shown you as I was going through building this deck, it seemed like we had already done a lot but then there's so much more to do. We have maybe five or six primary teams in the US. Are any of you like English Premier League fans? Parker? We also take it 25% of the Premier League, by the way. We just signed Manchester City like two weeks ago. So the future is bright. From an engineering perspective, there's a couple of things that I'm very excited about. It is to take our core platform and make it international which means there's going to be more types of payment methods. There's going to be more types of countries that we have to support, maybe more payment processors. And then also this idea that we built, the Seeking Enterprise is also known as this, in the US we also call it Seeking Open because we wanted to syndicate our inventory to every possible place. So there are competitors that we have that call our APIs to sell our tickets. And we want to keep going with that. And some of these use cases are very interesting because it's one thing to sell your tickets on a channel that is traditionally e-commerce, like Amazon was selling our tickets, that's very easy, like they have everything set up. But we want to target places that are not traditionally e-commerce channels, like a website that just shows you the latest scores and maybe they want to sell tickets to the Dallas Cowboys. So we want to enable all of this commerce happening. So there's a lot of really cool payment cases. Some of them we have already solved, some of them we're sort of working out on how to do. But the future is very bright from that perspective, from an engineering point of them. I know Nicole has more. Yeah, so not only do we want to empower the ecosystem itself, we want to empower the fans and we want to empower the organizers of events.  If you want to order hot dog at a baseball game or a t-shirt at a concert, we should be able to enable that and just hit your card on file. And then the team also knows what you bought.  Like these are all things that we think would be really cool to make every experience with payments just super seamless for customers while also providing a lot of value to people. And you're all peers, as we were saying before, but you're also fans, I'm hoping, and in a way, customers. So if you had never heard of Seeky, I just made this over there. So if you use the payments FN code on Seeky, you'll get $25 off. So have fun, have one on us. And if you know people that want to help us do this, we're also hiding, so talk to us after. But thank you. Yep, thank you. Thank you.


Hello, hello everyone. Good afternoon. This session we are going to talk about eBay, geo-distributed database on Kubernetes. We come from eBay. First, let me introduce myself. My name is Xinlong. I worked in the eBay data platform team. Actually, I'm a Kubernetes user. I'm not a Kubernetes developer. And this topic includes two parts in this agenda. So first, I will introduce the eBay geo-distributed database. I will share the experience of how we deploy such a database on the Kubernetes. The second part, my colleague Chenyue, he's from eBay Kubernetes team. He will do a deeper dive on the storage management in Kubernetes at eBay. We did a few extensions on the storage part on top of the Kubernetes. And this is the core thing to support us and running the database on top of the Kubernetes. So first, let me start from the vision of the eBay geo-distributed database. As you know, eBay, our vision is we want people to shop any item from eBay, from any place, any time, while any device. So we have the requirement to want the data close to the user. So that's why we develop the geo-distributed database. And the vision of this database is we want to provide a resilient, collaborative, and closely effective data platform to support eBay's global business. So we want it always available, and also it can be highly scalable to support the business group. And also it should be high performance. Since we deployed our cloud-native environment, so we also want to operation agility.  Otherwise, it cannot survive if we don't have this automation or cloud-native environment. So this is our vision of our geo-distributed database in eBay. So now let's look at how it looks like. So actually our geo-distributed database idea is quite similar like the other distributed database. So while we want to distribute the database, the dataset is too large. We cannot fit in one node. So distributed actually have two meanings. One, we want to split the large dataset to a small chunk of the dataset. In this case, we call it a shard. Actually it's a shard or range of key range. And physically we call this replica set. This is a replica in our database, not the same as the replica set concept in the Kubernetes. It's quite similar. So each shard actually contains a small range. It's just a small dataset of the global dataset. And the second of the differences we want to this data have a few copies. And these copies will be distributed on multiple machines on different zones. So that's the logical view of a distributed database. Now I have a graph to show how it physically deployed in a real environment. So the database will be deployed on multiple zones. On the bottom layer we call this storage layer. The storage layer just many storage nodes. Each node is a bare minimum machines. It's a physical hardware. In each storage node, we spawn a few database engine process on this storage node. In the graph, the same color actually means the data copy is the same. And the number I put in here just means the shard ID of the data. So logically a shard, for example, the number two shard, it will be in the first and the second and the fourth node. Actually this storage layer is quite large. The scale I talk about in here it will be thousands of this database engines. So how our application to access this database data to the read and write. Since we have thousands of the storage engines on the storage layer, we cannot let the application to connect to that directly. So we introduce a service layer. This service layer to routing the application request to the storage layer database engines. So this service layer actually it is a stateless. But how it can do the routing? Actually we have in the service layer it have a topology map to know the layout of the storage layer. But how did it know this layout? In the left side we call the orchestration layer. We have a coordinator. This is a coordinator, the service layer and the storage layer. The coordinator actively monitor all of the, actually it control all of the storage engines on the storage layer. It manages the state and manages the change. And it has its own metadata storage state. Meanwhile the coordinator also pushes this change to the service layer. So that will make the service layer kind of knowing our topology layout, the physical layout of the storage layer. Then it can routing the request based on this topology map. Meanwhile we also have the monitoring system. Because sometimes for this storage engine it may have some slowdown or some other problems. So this monitoring system also actually monitors the database engines in the storage layer. And it sends some signal in case something is a failure to the coordinator and the coordinator takes some action. So now what I have talking about is a gesture for our GOD's real database. But how it relates to the Kubernetes. So actually we deploy a whole sense including the storage layer and also the orchestration layer on the Kubernetes. So on the orchestration layer and the service layer actually it's typically the most so it's not a big problem when we deploy it on the Kubernetes. The core part is how we match this storage sense on the Kubernetes. We know Kubernetes is great but is it easy to deploy such a complex state of workload on Kubernetes? The answer is it's not easy. So now I'm going to talk about when we implement such a database. We found a few challenges when we deployed on Kubernetes. So the first one is we are talking about a distributed database. We have a GO distribution. So typically we will deploy this sense on multiple clusters. Typically Kubernetes is just our local availability zone or our local data center. It's just one cluster. So first we present each problem is we have to manage multiple Kubernetes clusters. We need to distribute our database engines on multiple clusters. So once we deploy on the multiple clusters we know Kubernetes has its own internal network. Inside it can have a good connectivity. But if you cross multiple clusters I have a database that has a three corpus on two data centers. It want to do some real-time reputation. So that we have the second issue is how we enable the network connectivity between the database engines on different clusters. So there's a second problem on the network side. Since we are talking about we want to do a high-performance closely effective data platform. But on Kubernetes by default if we want to persistent data we use the persistent volume. The persistent volume typically is a shared remote storage. But if we want to get a high-performance closely effective this cannot fulfill our requirement because remote typically means slow. It can maybe low IOPS. And shared means sometimes people can, the process running on the same storage will impact each other. And the next one is we persistent data and we want to a few data, we want to control the data placement because we are running our database. We don't want to same copy running on same machines. So there will be a risk. So actually we want to know the data location, we want to control the data placement. And another thing is we want to do some optimization. For example, when I brought in the request from our service layer to our storage layer we want to choose some close data node that can minimize the latency. So the database is more than like a pad. It's a very complex pad. It's more control of the process. The next one is in the database we manage the data. It's not just like your deployment. You have a pod, it's gone. You create another new product to add to the deployment. We are, we not only need to create the pod, we also need to move the data from somewhere to restore the data. So the changes we need some data lifecycle management. It includes data backup or data movement between a few database engines. So this is the main changes we faced when we tried to deploy such a workload on the Kubernetes. So now let's look at how we reserve this issue. So on eBase, actually we have a little bit advanced than the community. So I just saw the container network interface. So this maybe can also support the requirement like we did in eBase. So in eBase we assign each pod as a global IP. So that will make us on different Kubernetes cluster the pod has a network activity. So we have a controller. When I schedule a pod, it will assign a global IP. And this is global between the different clusters. So this will reserve the network connectivity issues. And the next we found if we want to use a very high performance, very high IOPS and also very dedicated volumes, we found only the local disk or the disk just maybe on same rack can be mounted like I discuss this local things. We can achieve this high OOPS and also dedicated without any impact for other neighbors. So this by collaboration with our eBase Kubernetes teams, we utilize the local disk as the positional volume. That means we can request the positional volume, but actually it return a local disk to this pod. And meanwhile, when we register this position volume as local disk, we put our physical location info like the rack and host inside as the labels for the local position volumes. Then can allow us in the application layer, we know the location of this disk and to know which rack it is and which host it is. Meanwhile, we enhanced the, actually this is also done by our Kubernetes team, they enhanced the part of the anti-affinity features from the pod level to the volume level, because when we schedule some things, maybe first I need a positional volume then I schedule pod. So we have some special implementation can also support a volume level anti-affinity. That means I for same shard data, I don't want to this shard the two positional volumes, not in same host or on same rack. So this will make us can get the high OOPS we can make our database high performance. Also we can support the anti-affinity this location sense. And next one is we found we will do the database. Database always need as a backup. If we somebody is broken even we have a multiple copy but we don't have like the time machine capability to know the history of the data. So the data backup is sort of quite important for us. We have a solution to to utilize the local disk this just like a device on the device level we do the snap short and keep sending the delta to sync it to network volume and use this mechanism for our backup. This local disk can still work with the high OOPS. And then it just keep doing the regular delta send the remote volume. Because if we just use the remote shard storage you can maybe doing the snap short on the remote shard storage. But now we use the local disk so we have additional this features to enable this backup sense. And now this is just on the infrastructure level we reserve the network issue and also reserve the disk issues. But we found after we utilize this feature we are not only we cannot use like a deployment or set because this just means Kubernetes can control your port life cycle. Now I cannot utilize because we have very special things like I need to control the local disk and port must be together. It cannot utilize these features. So then we choose a solution we could just use the port. We use Kubernetes to just manage these containers. And on the up layer we create our own orchestration layer to maintain the USB state. So that is the orchestration layer I mentioned in previous slides. Just we maintain our USB state. But how we can maintain the USB state? So first we have our own configured store to store our desired state. We also actively monitor all of the physical resources in the Kubernetes. Then we compare the difference to take some action like a loop as we watch the Kubernetes change and take some action to make it match our desired state. This is different like Kubernetes which obviously is more like a multiple data center because multiple Kubernetes classes and it maintains the USB while our own data store. Also we utilize since we call the workflow to maintain the USB. Because like I said before we have a few like data move, data operation and also Kubernetes operation. These are together. Sometimes I create a new port and need to move some data. So not just like a very simple operation it has a few complex steps. So we utilize the workflow mechanism to implement these complex things and maintain this USB state. Now here is an example for how I do the self-remediation. This example for example I have a replica. This is maybe the host that is down. Kubernetes deleted this replica. This is in red. We are watching this event. We are watching this event. This event will be sent to our coordinator. Actually we have two level coordinators. Each has its own local one. This will avoid one data center to impact others. We have a logically global one. It also distributed on multiple data centers. This local one will forward the event to the global one and the global one will make the decision and it will trigger the mission mission. I just sent our call to the local coordinator to create a new replica added to this shot. So this is quite similar to how Kubernetes works, but we just expanded on multiple Kubernetes clusters. So here is all of my talk. Actually I just share our eBase GO2 database and how the changes we are facing when we move on to this and how we solve these changes. And the core part of our solution actually is based on eBase Kubernetes storage management solution. And I also think this pattern is quite typical. Maybe it can be extended to as a high LPS GU distributed for workload. So that's all my part. I will forward it to my colleague Chenyuan for the next part. I'm from eBase Kubernetes team. My working domain is on OS management and volume management on the eBase Kubernetes cluster. Next I'll give introduction of storage management on eBase Kubernetes cluster. It supports GO distributed database. It can also support other eBase application as well. And here is the agenda of my topics. Here first I will introduce our storage classes. Next I will introduce our local volume solution, network volume solution, backup solution. Lastly, I will give a simple summary of our future work. Okay, storage classes. In our Kubernetes cluster, we define two storage classes. First is performance. It can provide 50K LPS and also maximum 500 MB per second throughput. The typical user case is Northeco database or some other eBase in-house application. The storage bank is local SSD. On Kubernetes it's our local SSD volume. The second storage class is standard. It can provide the 300 LPS or maximum 300 MB per second throughput. The user case like backup service or eBase ICD that Cassie can introduce yesterday's session. The storage backend is self-HDD based class. In Kubernetes it's our standard volume. Okay. Then go to the local volume. We started our local volume work last year. At that time, there are quite many network volume solution in Kubernetes but no local volume. We compared the network volume. We found that we still have quite many strong reasons that we must implement local volume. First is the performance. Actually, I think it's quite common sense that local SSD performance must be better than network volume. I think especially for the higher latency. We have a data test that if we write a 4KB block on local SSD, it takes about 200 nanoseconds. Why if we write it on the as Cassie volume, it takes about 1,800 nanoseconds. So performance local SSD is much better. Second is cost. We all know that commercial high-performance network storage is very costly. So the reason is availability. I think most of us will think that one local SSD reliability is not good and compared with network volume, its availability is not good as well. But actually, I think nowadays most distributed database actually management the data evaluated by their own. They usually have several copies on different nodes, on different disks. Actually, that means the data availability is guaranteed by the application level. So single SSDs reliability is not a big issue now. Also at that time, Kubernetes only provides the empty DR and the host pass as the way for pod to access local disk. But these two volume also has quite obvious limitation. So first, they don't support PV and PVC. Second, they cannot guarantee they are your size or IOPS. For instance, if a host pass share the same disk with root FS the pod maybe can use all the disk space on the root FS. So as this reason we start to implement our own local volume. Majorly, we do these three changes to the Kubernetes code to implement our local volume. The first part is local volume plug-in. We implement this plug-in to support hard disk and hard disk partition. This local volume plug-in is similar as all other Kubernetes volume plug-in. We implemented the major interfaces, like monitor, arm monitor, provisioner and deleter. And so we registered this volume plug-in in the Kubelet and the kube controller so that it works as similar as all other volume plug-in in the Kubernetes. Second thing we implemented PV and PVC. So user can just create one PVC for the local volume and use this PVC in their power spec same as all other PVC. For the PV creation, currently we only support static PV creation. So during the node provision, we will generate a config file. In this config file, we will indicate which partition or which disk can be used as the local volume. So when Kubelet starts, it will read this configuration file and it will create the PV instance in the ECCD and also mount the disk on the host node just like these two disks. So we can mount them first on the host and when the pod starts these two disks can be mounted in the pod's name space so that this pod can access the disk directly. The last part is changes in the scheduler. The reason is that local volume PV and PVC bounding is special. It's not the same as the network volume PV and PVC bounding. The reason is that whenever local volume PV and PVC are bounded it means that the node is also selected. This will break the later pod scheduling policies. So in this reason we postpone the PV and PVC bounding in the scheduler instead of in the PV controller. We did two changes. First is that we add a local volume predict function. So in this function we will check every node if it can fulfill the requirements of pod's local volume requests. And second is that we in the Kubelet's scheduler 1 function we do the final PV and PVC bounding just behind the the pod bounding to the node. So all these three changes in Kubernetes for us to implement the local volume. Here is an example that how can we use in the local volume PVC in our production. So we just define our local volume PVC I think as a storage class as local SSD. It's similar as the other PVC and in the part spec we just put the PV name so that's it. Here are several parts that we ever considered during our design and the implementation of local volume. First thing is where to do the PV bounding. I've mentioned before if we need to do the PV and PVC bounding in the pod scheduler or do it in the PV controller. As mentioned before if we do it in the PV controller then it will break a lot of pod scheduling policy. Like our customer geodistribute database they require the anti-affinity feature and also they define the pod memory and the CPU resource this kind of scheduling requests. So we must fulfill these requirements. So this make us postpone the PV and PVC to the controller. Another thing is that some features, some PV features will be, implementation will be more complex if we put this PV and PVC in the PV controller. Just like if one pod requires two local volume PVC. So if we do it in the PV controller then it's possible that one PVC bound to node A another PVC bound to node B then how can this part be scheduled. So as this kind of reason so we decided to put this PV bounding in the scheduler. And the second point is that how do we recycle the local volume. So when the PVC is deleted we also must delete the data on the PV. This actually at the very beginning we just start using the recycle pod way. So whenever we delete the PVC we start a pod and schedule this pod to this node. So using this part to remove all the data on the specified PV. At the very beginning we are worried about its scalability. But we test it to delete 3,000 PVC at one time and we found that this solution can still work well so we keep it in our production still. The third point is about disk failure monitoring and remediation. We know that disk actually is the most unreliable device in the machine compared with the memory CPU network interface so its failure rate is high. So currently our solution is that we start a demo set pod and call the some real controller CTL like Max AI or Smart CTL these tools to detect disk failure and whenever we detect disk failure and we send out alerts. For the remediation part currently we can only still do the manually remediation and this maybe will be improved later. Okay, then we will go to the network volume. I think network volume still plays a very important role in our netis cluster. One of the most important feature for the network volume is that it can attach to a node so but whenever the pod is deleted or crashed, so if user want to start a new pod or another node this network volume can still be reattached to another node and the pod can still use this same network volume. This is one of the most important feature of net volume in Kubernetes. Second thing is that I think when user using the net volume they suppose all the data availability has been guaranteed by the bank end of net volume like CIF. So they don't need to care too much about their application how to guarantee the data availability and will make user much easier. So this is the reason that we still need to keep the net volume in our production environment. We are using the single volume as our net volume solution. At the very beginning we are using the standard open stacks in the volume but after one year user experience we found that it has some problem. First is that it has too many depends on components. Second is that it cannot support bad mental. So as this reason we switched to using standarons in the provisioner from Kubernetes community. So this figure shows two different solutions. The left side we can see that this is the standard CINDA plus NOVA solution. This is a Kubernetes node. It's a VM. We can see how many components it depends when it's one to do the volume attach-detach. We can see he has a CUMUL, NOVA computer, RebitMQ, NOVA and CINDA. So in production, so every two of these components, if they have some data drift, then will cause our volume attach-detach failure. It occurs quite often in our production environment. That's the reason we switched to standarons in the provisioner. So by using CINDA standarons in the provisioner, we can still let users to use the CINDA PVC interface. But when users create standard PVC interface, actually the standarons provisioner can help you create an RBV or ASCASI PV in the Kubernetes side. So it has much less third party dependency. And it can improve the network volumes attach-detach reliability. Okay, then we go to the backup solution. Currently our backup solution is based on CINDA volume. Our storage team SAFTEAM has already implemented a snapshot controller. So like here, they have running a snapshot controller for each CINDA cluster. So when users create a port, and they create a PVC and if this PVC is net volume and this net volume is CINDA volume, so the snapshot so if they want to do the snapshot, they can send a request to the snapshot controller. This snapshot controller can trigger the CINDA to do the snapshot. And later when the client want to recover the data from the snapshot, they can send a request to the snapshot controller too. And the snapshot controller can make one of the snapshots via volume, CINDA volume and return the volume ID to the controller. The controller then return the UUID to the snapshot client. So when users get this volume UUID, it can create another port by specify this volume UUID in the PVC and create another CINDA volume PV. And this new port can use this recovery data. This is our backup solution in Kubernetes. Okay. Lastly I will give simple introduction of our future work. First is that we need to align our code with upstream of local volume. Especially tourist cargo upstream has merged topology aware volume schedule PR. So I think most of our required feature of local volume has been upstream. So later we need to do some work to align our implementation with upstream implementation. And the second part is that we need to do some disk and partition modeling during our provision. So that the purpose is that we can support multiple hardware SKU in our production during the node provision so that during the provision we can use in this model to specify which disk partition can be used in the local volume. It will be more generic solution. The third point is that we will consider the volume for the local disk. We want to take advantage of the powerful 5 systems DFS and some of the features of DFS maybe will help us to enhance our local volume something like snapshot this kind of feature. Okay. So this is all for my introduction. Thank you.


Over six months have passed now since 17-year-old Jeremy Jordan went missing in Bemidji. Our Josh Peterson spoke with law enforcement and Jordan's family members on how they continue to have hope. It was in the early hours of November 1st that 17-year-old Jeremy Jordan of Cass Lake was last seen in the area of Sixth Street and Wood Avenue. Since then, it has been grueling six months for Jordan's family and friends, helping law enforcement with leads and keeping faith that Jeremy will return home safely. It's difficult. It's difficult coming up here to Bemidji and, you know, not being able to not knowing where he's at, you know, not knowing what happened. Since last fall, large-scale searches have been held by air, water and ground, where volunteers and law enforcement combed the area looking for any sign of Jeremy. Even six months later, similar searches continue. Since I saw we've had a couple of boat searches, both involving canines and just so in our, we've also put helicopters in the air and a fixed wing plane in the air to, again, search the area where he was last seen and then focusing eastward. It's been over six months since Jeremy Jordan has gone missing from this location and what law enforcement say is frustrating to them is that none of the many tips that they received have led them to Jeremy. That tip that has, that has changed the direction or helped us to focus the direction on whether this should go one direction or another and that's probably the most frustrating. You really want to find a conclusion. You want to bring Jeremy back to his family or Jeremy's family. They continue to hope and pray for answers and ask everyone to help. You know, that's, we just want him home. You know, we want to know what happened. We want to know where he's at. In Bemidji, Josh Peterson, Lakeland News. Jeremy Jordan's family is currently offering a $5,000 reward for information that locates Jeremy. You have had contact with Jeremy Jordan and know of his current whereabouts. You're asked to call the Bemidji police department at<PHONE_NUMBER>. If you've enjoyed this segment of Lakeland News, please consider making a tax-deductible contribution to Lakeland Public Television.


What's up guys? Welcome to today's video. Today I'm going to show you guys a short men's haircut. We're gonna get into some to some clippering. I'm gonna do some clippering. I'm also gonna show off this Mitch product. I already prepped the mannequin with a double hitter, a two-in-one shampoo and conditioner. I'm gonna use the styling gel today by Mitch. And then the highlight of the day. The reason for this class is Calibrate Thickening Cream, which is a new product to me, but as a guy with skinnier hair I'm super excited about a thickening cream. Coffee, studio, let's do some hair. Here we go. Voila. So what I'm gonna do is I'm gonna do a quick clipper cut and then we can play around with the product a little bit. All right, so I want to separate top and bottom. So we're gonna work around that parietal ridge. You just really want to map out kind of where you want to put your fade in. I'm gonna be clippering pretty much all the way up to the parietal ridge. But this is the shape that I want to create in that clipper. So I'm gonna come up with my clipper, scoop out, and work around the head to create that weight line that kind of follows the head shape. I want it to be a little bit heavier in the crown. What I'll do to section this off is I'll comb everything kind of up and over like this. And that'll give me that rounded section. And then slide some clips in there. Good. Then we're gonna work across the back crown. I'll just keep putting clips in holding the hair where I want it. I'm gonna come around here and we're just clipping this away. So really just trying to get the hair out of the way of the clipper work that we're gonna do and drop the comb.  And as I work up into the hair, I'm just gonna kick and flick my wrist out to build up that weight towards the top of the haircut right at that parietal ridge. And I'm quickly gonna get this weight off of here because I'm gonna go a little bit shorter around the edges. But remember, this is the weight line that I want to create. As I flick my wrist, I'm coming away from that weight line. And then as I work up the head shape here, I'm still just going kind of straight up and out. I never want to go up into the head this way and start flicking up top because that's not naturally what the head shape wants the hair and weight line to do.  Here, straight up and out. So I'm just getting the bulk off for a second and then I'm going to focus a little harder on the details.  So I come up here, I dig the comb in and then I pull out like a 45 degree angle. So there's that. And I'm gonna go with a one and a half guard. Just work a little bit tighter on this edge. This is a pretty good standard length. Most of the guys I cut in this salon, like that are looking for just a, you know, a nice cleaned up clipper cut, are not usually going lower than a one and a half guard. So just a little flick of the wrist, still looking at this weight line here and then just transferring that weight line down here and following. I'm gonna bring these sideburns up. In this part here, I've bent the guy's ear down and I hold it with my comb flat to his head and I come around with my trimmer and that allows me to get in tighter instead of holding and having my bulky hand in the way. Then I work into the back here. Just cleaning up that neckline. This is not realistic right here. The only part that's really not too realistic is that little hairline area, which I would take my clipper and just kind of edge out that edge. So here is our calic. Now a couple things that we can do to get the calic to react the way we want it to, is to not fight it. One of the things that you need to think about is how does hair really work? The way that it works is as the hair dries, if you don't force it to do something as it's drying, once it dries, it's there forever. Until you wet it again. Wetting the hair breaks down bonds in the hair and allows it to be flexible. Heat also breaks down bonds in the hair and allows it to be flexible. So if you have a calic, the best thing to do, get it wet first and then hit it with heat and force it to do something that it didn't want to do when it would dry. The other thing that I like to do with the cut part of it, because the cut doesn't really solve the calic, but it can help out with the styling process. So if the calic is right here and the hair is swirling and this hair wants to kick up and over, what I'll do is I'll leave a little extra length in here. I'll work through cutting it and instead of cutting up over the round of the head, instead of taking it like this, I'll take it more like this. Now if I cut it shorter, that might be a instant cure for dealing with this calic, but when it starts to grow out, it just all of a sudden it's a problem again. Within a week it's a problem again. You want to be able to give them the most success that they're going to have in a three week to four week timeframe. So I leave a little extra length in this calic area just like that and I cut it however it wants to stick out. So if it wants to stick out this way, that's where I hold it and cut it. If it wants to stick out up and over this way, then I'll comb it over this way and I'll take my section diagonal like that and I'll bring it out and connect it and cut it. Either way, you want to fight the calic the least amount possible. We've got the hair cut kind of in the direction that calic wants to go. So now when I have my hair wet and I hit a blow dryer on the back and use a comb because combs pull a little bit more tension than a brush.  So here is another kind of point as I'm working through here. This hair kind of wants to kick over and spread and now I'm going to comb and cut the hair again where it wants to fall. One product that is great for working with a calic is Paul Mitchell Steady Grip Styling Gel. So medium hold gel, medium shine. I take this, I add the tiniest bit, no I don't, I take off the little foil piece, then I take a tiny bit, just like that. I work this into my hand and I work this right into the calic at the scalp. The scalp is what we're dealing with guys. Now gel gets crunchy if you leave it in the hair wet and it dries like that because it's just drying and keeping some of that moisture in and collecting the hair together. Rush or comb the hair where you want it to lay once you get the gel in there and then take your blow dryer and aim the heat and the airflow down. It's like this and work that airflow, do not move the blow dryer and now the hair is dry. We've used the two things that we needed to. We used water and we used heat to seal the bonds laying perfectly down as opposed to kicking up and being where it is. Now this until you wet it again will be good to go for the rest of the day. We're going to move on to the front and all I'm going to do is do a traveling guide across the top until I get to this high point here then it's going to be stationary. All right so the way that I'm going to work across the top of the head is I'm going to work horizontal sections across the top and I'm going to cut them flat parallel to the floor. I'm going to take a center parting comb it into almost like a bowl cut here and now I'm going to work with a traveling guide until I get to the high point so section one, section two, section three, section four. All of this will work this way. Section one I'll cut to create a guide then I'll go to section two I'll push section one halfway to section two section two halfway back to section one and we'll cut to create the next guideline on section two then we grab section three pull that back halfway to section two and we'll cut to that two creating a new guideline for four right so we'll just continue all the way up we get to the high point here then this becomes stationary and everything that we grab from the front which I'll probably just grab this whole front pull it all the way back to four and cut it right at this point and that'll give me a little extra length into the front. Section one also going to show you guys because I want to be cutting from short to long from this area here in the back I want to cut from the short piece it'll be my guideline here all the way up through here bring this hair up I do want to try to blend this section and then we're going to go into 90 degrees parallel to the floor again we've got a second section and this comes back pull it back but then I'll comb section one halfway to that section two cut parallel to the floor and then just bring it down a little bit and blend it into the side so it's a shift you first cut parallel to the floor with your guide and then you just recomb and then you blend it to the sides now we're still traveling comb it back grab a little bit of our previously cut section we're bringing this halfway parallel across the top and then a recomb and a connection to the bottom so now this is the last traveling guide up cut parallel to the floor and I bring it down and I connect it to the side and then I take the rest of this top and I bring it back to section four and I cut it stationary at that point so now I cut this side standing behind the head because I'm bringing everything and I want to cut short to long now if I go over here to then cut now I'm cutting in to out and it's very uncomfortable to do this so what I'm going to do now is face my client and I'm going to work in front of them and cut I'll go here and then four four is our last traveling guide four turns into stationary so then bring everything back so what I'm going to do is I'm going to blow dry this but I'm going to add in my thickening cream first this is the whole reason for the class today is for me to test out and highlight this thickening cream calibrate by Mitch so what I'm going to do is I'm going to work this product in put it in my hand working this into the hair working it in towards the scalp it's got a really nice slip to it I could actually see this even a cutting lotion when I started cutting into the top if I wanted to it would help me separate my sections really well to get full effect of the product I comb it through so it gets on every bit of the hair then I got my ergo diamond head brush okay so discoveries here first off I am like super psyched about this product because not only did like his hair feels super thick which his hair was already a little bit thick but not like not crazy but also it has more hold than I thought it would so I almost feel like depending on the style you're going for you might not even need a second product I mean for my hair I will definitely still probably use clean cut in it but I'll use much less clean cut this guy here it feels flexible like I could kind of move it where I want it but it feels just so thick so definitely psyched on this product but hey thank you so much for watching this video being a part of the comments and the community check out freesaloneducation.com for everything that you want and also become part of my patreon patreon.com slash mattebeck put it right here you get everything everything you need to know about basic hair cutting everything that I know it's in my head I put into that cutting system so go check it out on freesaloneducation.com subscribe like hit the notification bell and become part of our FSE community


Hurricane Ida made landfall in their New Orleans as a treacherous category for storm with sustained winds of 150 miles per hour. Ida caused severe damage and destruction as it moved ashore knocking out electricity for more than one million people. Many of them still do not have power in their homes or businesses two weeks later. As they continue to assess the damage incurred by Hurricane Ida, our sisters and brothers in the Louisiana annual conference need help from their neighbors in North Texas. We have set the ambitious goal of donating 1,872 cleaning kits, which you might also know by the term flood buckets. It's a five-gallon bucket filled to the brim with supplies needed to clean up their communities. From laundry detergent and dish detergent to scrub brushes, gloves, trash bags, we even have insect repellent. We have 14 conference churches encompassing each of our four districts that have volunteered to serve as depots where you can drop off the completed cleaning kits from Sunday, September 12th through Sunday, October 3rd. Information on drop-off sites and hours and instructions about the cleaning kits are available on the North Texas Conference website and these kits then will be transported to the UMCOR depot in Pawnee, Illinois in early October. The Sager Brown depot in Louisiana is closed at this time because of COVID and unable to have volunteers present there. So how did we come up with a goal of 1,872 cleaning kits? That is the exact number that will fill a semi-trailer and I challenge every pastor in the North Texas Conference to create at least one cleaning kit and even more importantly strongly encourage and in fact set a goal for your church for each congregation to take part in this important effort. I pray that you will join me in this important effort and I thank you all for how you do mission and you continue to do and assist those in need both in North Texas and beyond. God bless you.


Yellow jackets are a common problem in schools, however there are many other insects that are often mistaken for yellow jackets, such as honeybees, beneficial surfeit flies, and the paper wasp, a much less aggressive wasp than the yellow jacket. Before starting any management program, make sure you really have yellow jackets and not one of these other common insects. Become familiar with the seasonal patterns of yellow jackets so that you will know the best time to take action. Patterns emerge between April and May, and workers begin foraging late spring into summer. Yellow jackets reach their peak in August through late September. Yellow jackets feed on sugars and protein. Proteins are mostly favored during the spring and summer when larvae are developing. Sweets are favored in the fall. An essential component of a yellow jacket IPM program is prevention. But attractive food sources, such as sugar drinks, grease, and protein, at a minimum. Prevent yellow jacket activity as much as possible, especially around dumpsters, trash cans, and recycle bins by using liners, lids, and cleaning them daily. Seal holes in foundations, walls, roofs, and eaves. The most effective way to manage yellow jackets is to look for their nests and treat them. Nests are in the ground and have lots of yellow jackets coming out. If you find one, keep children away, and have it treated immediately by your local mosquito abatement and vector control district, or a licensed applicator. In some cases, traps may reduce numbers of wasps but are not nearly as effective as treating nests. Most commercial traps contain a chemical to lure the pests into the trap. Begin trapping in early spring to trap as many queens as possible. Keep yellow jackets away from students by placing traps away from where they play. For a more detailed look at IPM for yellow jackets, refer to the Pest Note on the UC IPM website. Rats can cause considerable damage in schools. They contaminate food and damage containers and packaging materials where food is stored. They can gnaw on electrical wires and wooden materials such as doors and ledges and tear up insulation in walls and ceilings. The Norway rat and the roof rat are the two most commonly found rats causing trouble in schools. The Norway rat is stocky and builds burrows along building foundations or in woodpiles. Indoors they tend to remain in basements or on the ground floor. Roof rats are smaller than Norway rats and are agile climbers. They usually live and nest above ground in trees, shrubs or vegetation. As they are found in attics, walls, false ceilings and cabinets. You don't have to see a rat to determine if you have an infestation. Rats are active throughout the year, mostly at night. Look for half-inch to three-quarter-inch droppings and gnaw food or wood materials.  Then or remove dense vegetation near buildings that provide shelter and travel bridges. Seal all cracks in building foundations and make sure there are no gaps larger than a quarter-inch under doors and in windows. When you have a rat problem trapping is the safest control method. Snap traps work best. For Norway rats place traps close to walls, behind objects in dark corners and where rat droppings have been found. For roof rats place traps on ledges, shelves, branches, fences, pipes or overhead beams. There are pesticide baits available. Do not use baits indoors because dead rats create bad odors. Seal buildings before baiting outdoors to prevent poisoned rats from coming indoors to die. Place baits in tamper-proof bait stations and keep them away from children. Rats can be poisonous to people, pets and wildlife. For more information on IPM for rats refer to the Rats Pest Note on the UC IPM website. Approach weed problems in the schoolyard preventively. Wherever possible eliminate bare ground where weeds can become problems. Use mulches in landscapes and plant competitive plants. Install concrete mowing strips in turf along fence lines and building foundations. Keep turf vigorous with proper watering, fertilization and mowing. When weeds get out of hand and must be controlled use non-chemical methods such as hand pulling where possible, flamers, hot water treatments and string trimmers. Look at what underlying conditions may be causing the problem.  There any problems such as leaky sprinklers and follow proper maintenance practices. Use herbicides only as a last resort and use selective materials. Use only the amount needed. Timing is important. Control weeds before they seed. For more thorough information on weed ID and management refer to the UC IPM website and check out the weed photo galleries and pest notes on weeds in lawns and weeds in landscapes.


Hello, my name is Trevor Youngberg and I'm a working wood-fired potter in Woodbridge, Connecticut So the most challenging part of making a piece is Revisiting it in a way that reflects my personality my interests now Oftentimes I'm working in traditional forms that people are familiar with like bowls cups and jugs But the challenge is figuring out What is it that interests me about this form? really why am I have I chosen to make this series right now and What am I going to concentrate on? What's the what's the sense? What am I trying to convey through this series and what I've oftentimes found is that It's not always very clear what I'm trying to say through that series and I found that with about a year's delay I could see how I felt where I was and what I was saying a year ago But right now it's not always You know, it's not point a to point b. It's not really clear cut I just know that I have this this drive and this need to make this form now And maybe later on know why The most challenging part of creating a life of faith Is navigating my way through Culture um What I love about pottery is that it's accompanied me from age 18 Until now I'm 46 So you're developing your identity You're developing your character From the first day I started making pottery. I was able to apply lessons learned in the studio to my life And so what I found is that in those years since I was 18 I've become more and more comfortable in my own skin My insecurities have diminished my confidence has risen so Find early on the challenge was more How do I exercise my faith and In society where it seems almost like taboo to even bring up Christianity You know, there's all kinds of pushback that you could find if you Come off being preachy with others And so for those many years in my early adult life Where I was just waiting to make a connection in some way With another Christian outside of my family and church, right? So That's happened In more recent years More and more often not only have I been more comfortable in sharing my thoughts and ideas But it's come up more with with friends somehow I've even had a really interesting conversation with a friend who's an atheist about a year ago And somehow through our conversation I was able to share like the rational side of being a Christian with him in a way that was compelling I'm not saying he's a Christian right now, but Through our conversation I had conveyed it to him in a way that he'd never heard it before And he's almost there I'm keeping up the faith that it'll come up a few more times in conversation over time but it's that it's that societal kind of like pressure And in combined with my level of maturity over the years that now I'm kind of to the point where I would I'm a Christian and if it ever comes up or if there's any opportunity to just address the fact that I'm a Christian I'm not perfect. I'm full of faults And just because I say I'm a Christian doesn't mean if I do something that you don't disagree with that You know somehow Christianity is is a farce or something like that, you know I'm going to mess up, but I'm going to admit it. I'm going to apologize too The way I keep growing and honing my skills Is by broadening the footprint of my pottery in general So early on I was focused more on working solo in the studio And doing everything I could that involved just my energy input into my work It was sort of like this almost like selfish focus knowing that there's a bigger picture out there But it was like really condensed on just me So as I've matured over the years, I found that that isn't a sustaining way of going about it It's a very necessary initial component But as I've matured, I found that okay, I have two little ones And I'm like a mature artist now, right? So it's not just about me or just about the sales of work, but it's more about what kind of Impact are you having on others? What kind of Friendships are you creating? What kind of experiences, you know, how How can you share this experience for bettering the lives of others? Which which kind of comes right back to myself? Like that sense of satisfaction isn't derived from just having a kill load of beautiful pots come out It's more about memories created, which is why I get back to the wood firing It's all about the lead up to the wood firing gathering with friends to split wood to glaze pot to load There's so much back work, you know the four days of firing is nothing compared to all the lead up time And so it's getting a group of guys together to work or friends women as well absolutely and Enjoy that process of putting in that work in that effort And uh celebrate, you know, just the time we share together leading up to it So as long as as long as I know that people's lives are being enhanced through these processes That's how I'll continue A passage in the bible that resonates with both my faith and my interest in pottery Is in isaia Three times It's it's referred to that god is the potter and we are the clay So my interpret interpretation of that that scripture Is unique to me because i'm actually a potter So when I think of that scripture, I think of god. Yes being the potter We being the clay in a sense that there's a relationship. There's a development. There's a discovery And as that relationship develops Just the subtlety the strength and the power Increases just like when you're making a piece of pottery you can bring an idea When you're working with that clay directly, there's going to be a growth There's going to be a change and something other than you may have expected And so that discovery brings delight happiness and joy And so that spurs you on to do the next piece If there weren't that discovery and that growth and that joy derived from the process I'd find myself Becoming interested in possibly something else. I'd get bored So there has to be that dynamic aspect to the process whether it's in my life of faith Whether it's in my pottery to keep that excitement about life kind of going


the CIA report caused a lot of discussion and fuss. What is it all about? Well, the CIA isn't entirely new to criticism throughout its history. It's been subject to various investigations that have been very critical about its actions and about its relationship with the policy-making community. But this one is particularly sharp in its criticism. It criticizes internal management, it criticizes the oversight arrangements, and it criticizes the effectiveness of the agency's methods. So what about the effectiveness? What is the criticism? Well, the criticism is that they don't work, that the enhanced interrogation methods that were applied by the agency after 9-11 up until about 2006 were simply ineffective. This, of course, has been disputed by many of the people from the Bush administration, Dick Cheney in particular, but the report is quite unambiguous in his statement that they added no value to the American intelligence mission. What has it been for the future of intelligence services, like the CIA, but also maybe Britain? It will put greater pressure on them to be accountable to policymakers and to be very, very robust in their internal management arrangements. One of the most striking things about the report appears to be the lack of oversight over junior staff who are in charge of these programs. So what does it mean for the oversight process as a whole? Well, this raises an interesting question for the oversight process, because the report appears to have split the Senate Select Committee on Intelligence. It was released by the Democrats and has been condemned by the Republicans and indeed by former members of the intelligence community who claim not to have been consulted enough and who are saying that the report's conclusions are flat out wrong in many cases. It's going to lead to an interesting debate certainly about the future of the oversight process and whether or not agencies like the CIA who have been given a lot of extra resources, a lot of extra manpower and a lot of operational freedom over the past number of years, over whether or not that they can be trusted with this kind of power. Is there any justification for criticising the report? There could be certain viable criticisms of the report. For example, over its research methodology it's been claimed by former CIA director Michael Hayden, for example, that they've been very selective in the way they've quoted documents or used documents and that they've not interviewed people who were involved in the program. These may or may not be particularly robust criticisms, obviously summarising six million pages of information will require some editing and the CIA has in the past been less than forthcoming about letting its staff be interviewed. For you as an intelligence scholar, do you think that there is now going to be a wealth of new information that will help you in your work and others? This report does give us quite a lot of new information about the CIA's practices since 2011, certainly a lot of it makes for very depressing reading. Less depressing reading is of course your wonderful book which we should plug quickly. This book is about intelligence gathering in the early Cold War and is focused on the all source intelligence effort, so using signals intelligence, using open source intelligence, using traditional spies to gain a better understanding of the Soviet Union's strategic, economic and political strength. Okay, great. Thanks a lot and happy Christmas. Thank you, Herr Busch.