Okay, so thanks everybody for joining today. I've got a really special story for you to hear, something that I was involved in firsthand. My name is John Wadley. I'm a principal architect at Red Hat. And I can tell you for sure in the last three to four years I've been involved with a bunch of engagements with healthcare businesses. And Red Hat has been heavily invested in helping healthcare kind of modernize their IT structure, right? We've been collaborating with Blue Shield of California. We have a special guest here, Tye Lim from Blue Shield of California, and as well as... Ooh, I get to introduce myself.  Not mic-ready. Still not mic-ready. That's our, oh, Olivia P. Varma, customer success executive with Red Hat. And I'm Tye Lim. I'm the manager of a site reliability engineering at Blue Shield. So this engagement involved all three of us, and it's a great success story of persistence and commitment to success and automation, especially on the OpenShift platform. So with that, I'd like our special guest, Tye Lim, to start with his story and our story. Sorry. Okay, so this is the agenda for today. We're gonna do an understanding of the opportunity that, and challenges that we face during our adoption phase, if you will, of Ansible and going into what we deployed Ansible into, or let me be more specific, Ansible Automation Platform, how we began that journey from where we were before we took a look at Ansible to where we are today. And then I'll just showcase one particular effort that we did with respects to moving our automation from various platforms, shell scripting, popped enterprise into Ansible Automation Platform. And then we'll go into what we're looking at for the future. So this is us, stuff on the Wiki page. So I won't dive too deep into this, but this is Blue Shield of California. We're a healthcare insurance provider based out of Oakland, and we have a ton of assets that we need to, in terms of looking at and how we manage our, referring to IT assets. And so this is what we're talking about today, is Ansible on OpenShift. Okay, so here I wanna focus on, a really touch on, I should say, what we did with Ansible at the beginning in terms of understanding what Ansible provided for us. The ease of use, the ability for us to reduce our toil with respects to, in terms of deploying our various automation frameworks, or I'm sorry, automation assets in their despair across the board in all of our IT organizations, and really consolidate everything into Ansible. On top of that, what we didn't wanna do was what we did before. We'll deploy a number of VMs to be able to manage and really upkeep that, because all the VMs that we needed to do in terms of what we expect the load to be on Ansible, that would be immense under many different types of groups with all their various automation jobs, really just hammering away at this environment. So we wanted to do something different, and that was putting Ansible onto OpenShift. And so we'll talk about that a little later in the presentation. Yeah, you really had a big landscape of opportunity there at Blue Shield. You had on-prem clusters with OpenShift. You had ServiceNow. You had a lot of toil with serving VMs, right? Yep. In some cases it took about a month to get a VM, right? In some cases, yeah. And then we had a bunch of different disparate environments that we were managing and having to deploy to for the whole release process, from development all the way to production. And then we took a look at all that and the big picture, and we determined that the best place for Ansible to be on is OpenShift. Blue Shield was trying to leverage OpenShift more and more, trying to containerize more and more. We just actually put their find a doctor application on OpenShift just recently. So that was the positioning and why we went with Ansible on OpenShift. Yep, okay. So I'll touch on this one here. This is where we are, how we built our strategy. Initially from 2021, 2022, up to where we are today in 23, and what we're gonna be looking at in 24. So back in 2021, we really wanted to understand where our automation was. And right now at the time, it was popular enterprise, but it was also only focused on the middle work portion of automation. And so groups such as our storage teams, network engineering, and a few others, really just focused on what they can do with shell scripting, Python scripting, and pretty much homegrown type of thing. And it wasn't a common framework across multiple teams. And so trying to understand everybody's automation strategy was very difficult. And so as we ventured into understanding what we need to do in the cloud, we really need to rein in everything and understand how we can actually build a common, or adopt a common automation framework. So we started to look at Ansible, or more specifically Ansible Automation Platform. And so we'll get to do, I'll talk about how we began that journey and essentially got to the point where we partnered with the professional services to be able to do that effort. Yeah, so I mean, one of the messages I always say a lot of times is automation, disparate automation in different teams and across the organization and different types of technologies. That's not, in my opinion, automation, right? That's still back in the days of everybody has their Bash Script, right? Just everybody has their different type of Bash Script. So that's not what we're trying to do here. We're trying to have a single platform, a single platform where everybody can collaborate with, reusability, right? And then you saw just earlier event-driven automation is gonna leverage that for remediation, right? You can't do those types of things if everybody has their own kind of cookie and recipe, right? So you have to have that platform and central that platform for automation as a start. It also helps to, and you'll hear about this later, start to build a community around that, right? Which is an ideal way of getting that enablement throughout the whole organization, so. Oh yeah, and then last year and into this year, we again partnered with Red Hat Professional Services to be able to understand where we're gonna do take our puppet enterprise environments, our various modules that we've written and migrate that over to Ansible. So we'll go into a little more detail in a bit, but we wanted to be able to understand where these various groups were building their automation in puppet, and then how did we have to get to the point where they deploy into Ansible. And ultimately get to your cloud vision, right? Which is, it was at a moment when you were trying to say, okay, we wanna get to cloud, but we wanna do it the right way, right? We had this experience with on-prem, not the best was. And we wanna make it a lot better going to the cloud if we're gonna make this decision there, right? Exactly. And then in our decision of why we went to OpenShift for Ansible versus just deploying a number of VMs. So we'll touch on that as well. And then what we're looking for beyond is where are the new tools, new processes that we're gonna be actually looking into? Managed services on Azure is one aspect of what we can probably take Ansible to the next level. But so that's what the future we're looking at. Let's go to the next slide here. So here I'll be talking about how we began our journey, what we did, how we went about going about doing it, and what we eventually wanted to actually accomplish all this whole thing. And the proof of concept was the beginning or the emphasis of what we're gonna move into. So we had a few challenges, but we also had opportunities. And so as I mentioned before briefly, that we adopted Puppet Enterprise internally for some of our automation and really focused really on just middleware. And the groups that did not adopt Puppet Enterprise they shied away from only because of the the immensity of trying to understand Ruby as well as Puppet's DSL in terms of how to develop their automation. And so a lot of groups like networking, storage, and a few others, really they weren't focused on being developers. There were more administrators trying to manage the platform. And so the struggle there was trying to get them to adopt a framework. So Puppet never came to fruition for some groups. Other groups that were more developer focused such as the middleware teams really took Puppet into embrace Puppet, but it had to be a really had a developer mindset to do that. So the opportunity for us with Ansible was the ability to essentially develop our automation without the need for complex code such as Puppet. So we were able to write our YAML which is such a plain English to be able to describe what we want and deliver the actual final product. Excuse me. And then as we ventured on to cloud deployments we also needed some, it was another issue there where we need to understand how we were able to manage to automation. Homegrown scripts, Puppet, they weren't really good use cases for us. And so what was in terms of how we want to be able to deploy assets into the cloud. And so I'll talk about that in the next section but in terms of how we wanted to address the cloud Ansible fit our needs much better than anything we can actually utilize. And then we wanted to rein in all the various applications sprawl that was occurring in our environments. We had so many ways to deploy a J2E environment and multiple groups actually deploying that but then when it came down to it one group were doing it one way, one group was doing it another way but then they're all achieving the same goal. So one of the things we want to rein in with Ansible was to consolidate everything as well as put everything into a single source of truth in terms of hey, this is how you deploy a J2E environment. And if you wanted to do something more customizations we can develop workflows to actually really understand how to deliver a specific area or environment customized for a specific request. Anything you got? Yeah, just the application sprawl and silos bit. One of the things that we introduced is the concept to kind of address that because it's really hard to kind of dive into a customer and say, hey, that application, that application, that application kill them, we're going to move on to here. You just can't do that or at least I'm not there for the length of time it needs to happen. So we kind of talk about orchestration automation and I talk about try to do something today that helps you get to your long journey or your vision. So connect the dots first even if you don't want all those dots in the future but connect them and at least alleviate the manual problems around the integrations between the systems. So they had service now, so we tried to elevate and some type of workflow implementation for orchestration around those applications in order also for them to understand that applications a little bit better and why they do need them or don't need them. So when you bring the community into one application or one connected workflow then you kind of have them all understand what's really going on here. But when each piece of the flow is handled by a different team then nobody cares about anything but that little silo piece, right? So it's one step towards solving the big problems which helped a lot. Yeah, it's part of when we were doing a lot of the migration stuff a lot more collaboration in terms of getting things into Ansible understanding the various teams and what they did what they did and then really just really understanding or breaking down those silos in terms of, oh, this is how you deploy this particular environment. Oh, we can add this functionality to your playbook as part of this whole effort. And so a lot of that was happening as we collaborated in terms of how to rein in a lot of these redundant scripts if you will and really consolidating into a single source of truth in an Ansible playbook. All right. So how did we begin this journey? Q1 2022, we approached Red Hat Professional Services to begin the journey in terms of how do we adopt Ansible? At this point, it wasn't how do we adopt Ansible in OpenShift, it was how do we adopt Ansible? And so we had various groups, as I mentioned before, networking Unix and a few others that really wanted to explore how Ansible would actually fit their use case. They're all specialized use case for automating storage, automating network, excuse me, network assets, you name it. And on top of that, as part of the effort as well, Middleware and my old OpenShift team in terms of how to utilize Ansible to manage those platforms. So we began a journey in Q1, it took an entire quarter to actually look at all the various use cases and really develop that and put that into a proof of concept environment. Our proof of concept environment was actually deployed on an on-prem VM, a vSphere VM, and essentially essentially just deploying AAP there to be able to do what they need to do. And so, but one of the things that we did that came out, came out of that effort was as more and more groups were deploying into Ansible, we did see performance degradation in terms of all the people utilizing that one VM to do what they need to do, which later on made a much more better sense in terms of where we wanted to put it, which was OpenShift down the road, which I'll go into to that factor. Yeah, this collaboration was important and this step was very, very vital because it was kind of like a redefinition of how BlueShield even does their intake process, right? So we talked about application sprawl and stuff. The habit was we buy an application, we use an application, right? In this case, it wasn't, we buy an application, we have this, let's try an application first. Let's not over commit ourselves. Let's just play with it for a second, get used to it and think about how we're gonna use that across our whole landscape, right? So we didn't worry about the installation of Ansible, we did it on the standalone server as simple as possible, as basic as possible, but we focused on the product itself and the value that it brought to the business. So that was a win-win for Red Hat and for BlueShield together and a lot came out of that. Oh yeah, all right, so as I mentioned before, I'm gonna talk about migrating over to the Ansible platform, why we chose OpenShift and essentially talk about what we did in terms of scoping out or working with the development, IT development teams to actually migrate from Puppet Enterprise to Ansible. And so, why Ansible? So I mentioned before the application sprawl, the technical debt, the various amounts of Puppet modules that we developed from various teams to be able to do the same thing. So with essentially the complexity in the code for various Puppet modules, depending on what it was addressing, the learning curve to understand what those modules did was really steep. So a lot of groups really took a long time for them to be able to understand how something got done and replicated. And another thing too was when those Puppet modules were developed by contractors and they leave, well, the guys who have to support it, they still, lot of them did not adopt the understanding for wanting the desire to understand Puppet, so it got that much more complex. Another thing we looked at with AAP, which was great, was the development of REST APIs within the platform. So I mentioned that we're already utilizing AAP to do a lot of our work, but one of the things that we also did was, or utilize, is that we were able to build those REST API calls and essentially incorporate that into our scripting to be able to call out a function, say, deploy a resource group in Azure, deploy a VM in Azure, develop that workflow, essentially through these various calls or a call to that workflow. And so the REST API integration in part of the platform was a great feature for us for able to really execute what we need to execute. One of the things that we're also looking at is how we incorporate these REST API calls into something like Jira. A web book in Jira to be able to execute when a particular Jira issue is created and be able to, say, deploy an environment through the execution of that REST API within the Jira framework. So that's one of the things that we're looking at experimenting with in terms of how do we streamline our operations in the utilization of Jira. And another reason why? Yeah, it was just easier to read. So again, mentioned before, Puppet, now being adopted by various groups, those very same groups that didn't adopt Puppet took to utilizing Ansible much more easier in a less time frame. During the Puppet migration effort, we had like at least four different groups that had built out their entire framework around Puppet Enterprise. And so we had a time frame of three months to be able to get them off of Puppet Enterprise. We were thinking of not renewing the license for that. And so we were able to essentially go from zero to 100 in less than 30 days. We took their Puppet modules, working with professional services to understand what those modules did. And they coded their playbooks to mimic what they exactly did in their Puppet module and put that into Ansible. And roughly three days from concept, from concept to deployment to production and we're managing our environment. So the two teams that were actually, that really proved the use case was our database team and our middleware teams to actually look at where we were, where they were in Puppet Enterprise, to where they need to be in Ansible. And so we were able to get them all up and going inside of a month. Yeah, the last bullet on the top section, the ease of use and adoption, that's so massive and all the engagements I've ever been in. My focus has always been on enablement and adopting Ansible or adopting automation as a cultural kind of knee-jerk reaction. It's something why, for example, we have Ansible Lightspeed, that you just heard about this morning and AI enablement and to write those playbooks because we're trying to get people that aren't coders to write automation. And so to do that, you have to help them bridge that kind of gap. And I would say at least Ansible does that because we're leveraging YAML, we're talking about desired state, we're not talking about if then else functions, complicated coding practices, we're just talking about very high-level descriptive language. So that's why that AI Lightspeed is like, I want to install a VM on Azure, and then it plays out the whole task for you and done. So that's the kind of idea that we wanna do when we work with customers, is try to enable various teams no matter what your skill sets are to get you to start thinking about automation. And then the last part, yeah, so why did we put a Ansible automation platform onto OpenShift instead of just deploying a number of vSphere VMs and like how we traditionally do our various platforms? So one of the toil issues that we have is expanding our VM environments to meet particular performance requirements. Say if you have a J2E environment, you wanna add more processing. Sometimes you add more processes on there like more JVMs and such. And sometimes they're occasioned where we have to deploy multiple VMs to low balance against. Well, that's great, but we wanna do something a little more different and maybe a lot more easier than that. So we looked at OpenShift. What are the scalability aspects for OpenShift? Well, we can auto-scale number of replica sets in terms of number of pods we can actually deploy into a namespace of a particular application. In this case, it's Ansible. So we can set up all scaling that way. Another aspect was if we needed to, we can auto-scale the number of worker nodes to be able to horizontal scale that way in terms of adding more capacity. Like as I mentioned earlier as a setup that when we're doing a POC, one of the major things that we saw was performing degradation in that single POC server, that proof of concept server. So where we saw a lot of jobs being implemented, but then some jobs were taking longer to execute. And that's because we had a small VM to be able to do this proof of concept against multiple groups doing all their various use cases against. And so the, and this is just there for, OpenShift was how do we reduce the 12 of us having to scale all the time depending on the growth of our automation? Well, OpenShift provided that. We'll be able to auto-scale on a various needs to be able to essentially define that threshold, say CPE goes over 80%, well let's deploy another worker node and meet the capacity there. Another great aspect of it was we can also draw down the number of worker nodes or number replicas sets depending on demand so we can throttle up. And then throw all down. That was a big factor for us because we didn't wanna be able to constantly babysit something where we had to keep deploying more and more service to accommodate. OpenShift provided that ability for us to do that. Yeah, and it's also a consuming resource, resources that you didn't have, right? Like you have to also think about a lot of customers that wanna automate. They're not in a situation where they have unlimited resources to do lots of wonderful things, right? Usually they're in a limited resources situation and so they're trying to squeeze in some automation to try to do more, right? That's not the situation when you wanna set up a hugely complex type of infrastructure and solutioning that'll be self-managed by people that don't have time. So we have to think about scalability, we have to think about ease of upgrades, we have to think about reduction of resource demand so that we go back to the top part and say let's enable automation, right? Let's focus on enablement of automation, not focus on just managing a platform all the time, right? So that was one of the big things why we went with that and of course that they had OpenShift and the skill sets already around OpenShift so it made complete sense and they had this thing around, of course some of you have maybe Ansible Tower and it's End of Life so that's like another great opportunity to look and reevaluate where you want AAP. So that's something to think about. The last part is there's of upgrades. We had the VM sprawl that a lot of people, a lot of places have. We didn't have to upgrade various servers to do to put them on the latest and greatest version. We just had to update the Ansible operator in OpenShift and you're done essentially and then really move on from there. So it really became that push button effort for maintaining Ansible on OpenShift. And you can always evolve your infrastructure and your solutioning to be more complex and to be more advanced, right? But try to start with something simple and that's gonna satisfy your needs. Yep. Okay, so this is the puppet migration I wanna touch on this a little bit in terms of what we did. So again, with the help of Mr. Wally over here, we took, we didn't talk about with the various teams, what did you guys do? What, we had a scoping effort. We understand where they were, where they are and what they're currently doing with Puppet and really modeled what that would look like in Ansible. And then that way we prepped them for what they needed to do to do playbook development. And so which really from scoping, scoping I think would took the longest. Yeah, the scoping thing was really an important prerequisite and what that entailed was about six different calls that we had together working with each of the SMEs from the different teams that understood the Puppet modules and code and try to understand at a very business value and business stream direction, what are they trying to achieve? And then because ultimately it's a lift and shift because it's, Ansible works a little bit differently with desired state code. So that scoping kind of session really helped us quite a lot to be able to then put together an engagement that can actually drive through and build those. Yeah, and then we went from there to development which for the groups that were involved took about 30 days to actually go from zero to production and then from there utilizing the platform and deploying the platform out to the various environments. You really wanna understand what is being used by Puppet but more importantly what's a priority and what brings the most value to the business, right? Because it's again, it's a moment to pause, crawl, walk, run, pause for a second and evaluate, did we even need this automated? Did we do it right? I mean, what are we doing here? And then determine how it should be in the new world, right? So again, we were doing it the right way and the flow shield was slowing down. Yeah, I think in one instance, we went part of the scoping effort and part which went into development was one group realized, oh, we don't need this. And there was an epiphany moment, oh, we can take this out. Which was great, which means we reduced the technical debt as part of the whole process. And that was because the application was gonna be decommissioned next year. Exactly, yeah, something like that. So there was no need for effort in that, so. Yeah, so that was actually a great aspect of working with you guys. So what's our roadmap look like? Well, we did our initial purchase of Ansible last year in terms of the first set of subscriptions and we started applying that to interning in a very limited fashion. But as we started to adopt it more, we increased the number of subscriptions and we increased our scope of where we're taking it. Initially, as part of the effort with the POC, that was more focused on on-prem. But as we dived more into the cloud and building our cloud strategy, a lot of the effort now is focused on how do we manage our resources, our IT assets, in the cloud with Ansible. So I mentioned earlier that we're looking at Azure. How does managing resources at Azure look like in terms of deploying a resource group, a resource mapping, and a VM or managed service? So we're looking at those things today in terms of how we're gonna be able to do that. And then really 2023 and beyond is looking at other functionality or which we can actually deploy into Azure 4. Other managed services, other things that can help support our Ansible narrative. So I'll look into the future. So really it's about cloud automation for us understanding where we're gonna be going in terms of how we're gonna be managing our resources, not just Azure, but other platforms as well, GCP. And then really looking at how do we leverage that? How do we evolve our current Ansible environment? Well, today we're on Ansible and OpenShift, but the potential for Ansible on Azure is there. So looking at that managed service as part of probably a potential future strategy. And then really building a service catalog of all of our various REST APIs where groups can just look at our catalog, pick out what they need to perform a particular action, call that REST API, and do what they need to do. So we're looking at how do we organize better our automation in terms of how can other people consume what we develop or whatever group writes and how does other groups consume their efforts. And then today we have a steering committee that helps guide our Ansible efforts. And then building what, and Olivia will go into this in a second, our community of practice. How do we get other groups within Blue Shield to actually to understand how to get onboarded into the Ansible framework, how they utilize it, where they can get resources to help develop their application or their automation, excuse me. And you're essentially going from there in terms of how to support that. I think that's your word. Yeah, okay, I don't want to yell at everybody here. So throughout the presentation we've been talking a lot about the people building a community, adoption. So when we think about the community we're really thinking about, like Ty said, a community of practice. It's not a new term, I'm sure most of the folks here have heard it, obviously according to the pictures it's been around for a long time. But if you don't know the term community of practice it's really just a group, like I said, a community of people that are coming together with a shared interest, a shared passion. They want to address a problem and they can do that through ongoing interaction and engagement with one another. And we at Red Hat unsurprisingly really love community of practices as an open source company. It's an opportunity for us to allow folks to come together and maybe build a partnership that they would not have otherwise. They can spread knowledge through discussion. They can learn about new tools and they can bring that back to their respective customer sites, they can bring that back to their groups, you name it. So talking about it in the context of BSC was really exciting for us because I think John mentioned this word a couple of times, adoption. My job in customer success is really focused on enablement, adoption. I'm not going to ask for a show of hands here but I'm pretty sure if I did. If I asked folks here, have you ever purchased a technology or product or sold a technology or product that became shelf wear, right? You bought it, let it sit on the shelf, we'll deal with it later. I'm sure a lot of you here probably know something about that. So community of practice is a great way to introduce folks to that new technology, that new solution and have people start talking about it, and that ultimately and organically will foster that adoption that you're looking for. So why are we talking about it in the context of BSC? Well, we're super committed to the long-term success of all of our customers and that obviously includes BSC. And when John tapped me on the shoulder when they started this Puppet to Ansible Migration project, we saw that they were already doing it in a really cool way. We didn't call it a COP, but it really was a community. I think Ty mentioned the daily working sessions that they had set up, hours each day. Different application owners would come together in partnership with Red Hat and they would talk. They would talk about their problems. Hey, what issues are, excuse me, what issues are you experiencing today, right? And migrating over to Ansible. Hey, I just learned this really cool thing, right? Oh, I just saw somebody do this. Let's talk a little bit more about it. So they were already naturally coming together and they were getting really excited about it. So we saw a really great opportunity. And so John and I approached Ty, talked a little bit about the concepts, right? Red Hat's perspective. Keep going. Oh, sorry, it's just here. I'll just exit out. Yeah, yeah. But talked a little bit about Red Hat's approach and that's what I wanted to quickly share here. Mission and goals, establishing that at the very beginning is critical. I remember when we had the initial conversation with Ty, he said his goal was to establish Ansible as the enterprise organizational wide automation platform, right? I was thinking about that for the past 30 minutes. That was his vision. That's what he saw. And so now we need to figure out what our tangible goals are, right? How are we going to do this? And then we document it. We document it so it's something that's true to us, true to the group and that we can share that broadly with the team. Sponsorship. Ty also mentioned briefly about an automation steering committee, right? We need a group of folks that have the leverage, right? Do some of the clout at the organization to help us make sure a few things, to help us make sure that we are aligning our community of practice goals with the organizational goals to make sure that we will be successful no matter what, right? We need those folks to help steer and guide the direction but also make sure that we're evangelizing throughout the organization, that we're removing any impediments to make sure that we are successful. Roles and responsibilities is key to identify early on. Poor folks like Ty probably have to, you know, bear a lot of the work early on on their shoulders, right? It's a group effort. It takes a village but establishing those core roles, the leadership roles to really get it off the ground and going. A great example of this we talked about putting together at the early days. Just a quick presentation. Hey, this is a COP or this is what we're trying to do here. This is why it's so awesome. This is why it could benefit you. Somebody like Ty as the key driver of that COP can start to bring that to different groups in the organization. Hey, this is what Ansible is. This is automation. This is what it could do for you, right? Start to figure out ways to bring other folks into the community. Tooling and resources. We want, we want to make it easy for folks to onboard to a solution or to the platform, right? Having a common repository that people can contributely, excuse me, regularly contribute to and take away from is absolutely key. And it could be something super easy. Could be your Microsoft team, SharePoint, whatever it looks like, but have a place where folks can access so they can onboard quickly and easily. It's all about information. That's what it's truly all about. And then consistency. And this is probably the one where everybody's like, oh, yeah, yeah, yeah, yeah, we'll be consistent and nobody ever is, right? But it's figuring out what your cadence is and sticking to it. Community, the purpose, again, like I said, the definition is people meeting regularly together, right? So figure out what your cadence is and stick to it, right? Bring in a variety of topics. You can have a working agenda that other folks can contribute to. Hey, I heard about this cool thing the other day. I'd like to talk about it a future COP. Whatever it looks like, have a place, a common forum and continue to move forward. And the last thing I'll say, and it's not here on the slide, but it's all about measuring your success. I mean, it's in general just, excuse me, important to do that anyway. But I think having a place where we can continuously show to the folks of the community the progress that we're making, the outcomes that we are achieving and striving for, the data goes a long way. It's an incredibly powerful message and it will continuously help you invite other folks into your community and then also be an opportunity to galvanize your community to continue to grow. And so with that, I'd like to pass it over to John and he'll provide a few examples of some of the success metrics that we've collected thus far with this project. Thanks, Olivia. You keep that. Oh, I guess, okay. I got my portable one. And just before I hit that, just wanted to, I like the consistency part. Consistently inconsistent, right? But also on this, I just wanna note, there was a moment on the calls when we had with Blue Shield when I was like, it was an amazing moment that I appreciate doing the delivery side of things. And it was when a Blue Shielder said to another Blue Shielder, I don't know if that's a word, Blue Shielder. It is now. Sure, it is now. Yeah, what did two Blue Shielders say on an automation community? Yeah, fellow Blues, there we go, two fellow Blues. What did two fellow Blues say on an automation community call? It's not a joke. And they said, hey, that is not acceptable. That's not our standard, right? You need to change that code because that's not what we've been talking about for the last month, right? And I was like, I don't need to say that anymore, right? That was the moment when Blue Shield was owning their automation and their standards, right? That was this really sweet moment. Anyway, so onto the metrics. So here's some of the metrics. Some of them are a bit young numbers, I'll say, because they just started, right? But they're awesome numbers. So we have six OCP clusters that are also being managed a little bit by Ansible. We have 120 people already in the community at least, and that's growing today because we're also helping their security team do automation. 2,500 hosts now already in the infantry and Ansible platform being managed. 733 templates, mostly to manage their cloud kind of VMs and everything, right? And networking. 95 users, pretty impressive. Those are active users, to be honest. Yeah, and still 75, it says there. That's 75 Ansible teams. Okay, so 75 Ansible teams, not teams in Ansible platform. And three different regions. So obviously Blue Shield of California, it's being mostly in California, but they're also leveraging Azure. So some really fantastic numbers to kick it off. And with that, the last words, final words as we would say, maybe Ty? Yeah, so we're still at the beginning of this effort that we're doing. And so we're running into issues, but then we're also understanding the challenges and that each one of them are essentially gonna become opportunities for us to do better. And so really, we're at the beginning stages of our effort in terms of Ansible, the cloud and a few other things. And so the point I'm trying to make is, we're just gonna keep improving on top of what we did before. It's a journey, right? It's a journey. Yeah. Yeah, and I would just add to that. It is a journey and like Ty mentioned, they are at the beginning stages, but we are too, right? Lockstep partnership with BSC in this journey. We're, it's amazing to see the progress over the past year. It's just been amazing to see their strategy unfold and we're really excited to continue to work with them to support it. Yeah, my last words is basically, thank you Ty Lim because these types of things are not possible without somebody who's like devoted, devoted as an automation evangelist. I like to use that term evangelist. I mean, there was never a day when he didn't give up, right? And you need that kind of persistence and perseverance, at least from a red hat side to work with, because it's not easy to change a company like Blue Shield and other financial companies and all these other companies that are trying to transform. It takes time, but it takes small changes each day. And if you believe in that over the longer term, it becomes big change. So change can be easy if you do it in small little increments. Change is hard if you think too much, right? Too much at one time. So anyway, I just want to say thanks to Ty on that one great success story and that's it. Thanks guys. Thank you, appreciate it.


Going on everyone Sam here with late in sports cards from 23 tops inception baseball hobby 16 bucks full case break number 30 Random team style. There's a look again at your random results as always you find those on the website under the results tab As well as the link in chat. So good luck everybody. Let's get make a dual case filled up Let's go last bath baseball break of the day 3 30 a spot full case of this inception And then full case of definitive baseball, which is kind of looking we've hit some massive cards out of This too like inception is nothing to scoff at either Deception's been good man. We crank through inception dude. We've got like six cases left or something We flew through inception because it's so good this year Everybody likes it. So who's a bit like who's ever really chasing in this year? Obviously Clark obviously laneford obviously schemes Matt Shaw is really good Insanely yeah, oh my god number one for sure. There's Beatty rookie Nelson Velasquez to 99 for the Cubs Yeah, and then outman. Yeah. Yeah. Oh my god Raffy Devers and George Kirby to 75 on the color match teal for the Mariners On-card something here Jake Might be just an extra hit Nice Max Meyer purple netto to 150 and Oscar Colas base base Lou Bob Z kill to ran to 25 for the Rangers Jacob Wilson for the A's nice one there. Okay. I like it and nice Joey Weimer 42 of 99 first milestone. That's sick. Let's go. Congrats brew crew. It's got Milwaukee Dude, that's awesome. Ryan L. Congrats Ryan. Good stuff there, buddy Good stuff there Ryan L with the Brewers very nice very nice One of the big chases they added this year for inception are the milestones That is Anthony Volpe Vaughn Grissom and Cole Ray's again That is the first career a game use base from the first career hit of Joey Weimer's career Tristan Kossas and Oscar Gonzalez 249 Congrats on that Guardians new Yankee Oscar Gonzalez, yep, let's go. Jake's got us watching the weather channel. Let's go Oh, yeah, Jake, let's go, baby. I'm sorry Food to nomi green Hunter Brown Rookie Abrams, Parazza and Jordan Groschans three or four colored RP at 149 grads on that one there Marlins We go Malins Silver SIG on release day. Nice. Let's go Carl. Oh, yeah Rafi Devers Purple Paul Goltz mit to 150. There's a lot of bots here on Friday Patrick Bailey, do you notice that as well? Yeah, a lot of bots here. I'm sorry. I was I felt like I was in One of our four-night lobbies Jordan Diaz the 99 surrounded congrats on that one. They're eights very nice very nice Yeah, it's one again. That's yeah, it's like they're they're surrounding me Can't get away. Alaska is green. That's all I hear is a little gliding noise to 150 Jared Walsh And people landing and pickaxing walls Immediately don't panic to ten. It's Michael Stefanik. Wow blue auto congrats on that one there angels Let's go. Thank you Jason a two mega dual K-spots and four in Star Wars masterwork Jason. Thank you, buddy 18 left 18 to go in mega dual case everyone 18 to go on mega dual case appreciate you brother mega dual case Thanks Jason as always do appreciate you my man and four of course in Masterwork not gonna stop under 20 on the second break now number 12. So very nice sold out on 11 believe 18 to go now on 12. I Was gonna say I think you did you did behind the brakes tomorrow Scots carrot Mitchell Javi Baez and Bryce Thuring It's all good.  Got you tomorrow 299 Alec Burleson. Yeah, absolutely RPA green for the Cardinals It'll be a good time. Absolutely. Oh, it's a really sting No sock The overbequero Ozzy albis and masataka Furnair mix, but what else did he say to there's another really funny one He said I gotta think about it we over a quail Corbin Carroll to 125 fact-to-back cases. Wow Nice one there CC 7 zone. There you go zone and RPA of Jonah Bride 38 of 75 for the aides Congrats Like that one I know I did kind of like your champ bailiotto on Facebook.  That's pretty fire Purple Aaron Nola 150 Gray rod, I mean, it's lucky then illegal last two players were seven and 77 Adley rookie and Brent Beatty 15 of 25 nasty RPA congrats on that one Mets. There you go Mets Forrest and Jake tomorrow at 5. I was yeah, yeah 5 p.m. Eastern time me and force will be starting at five Couple of knuckleheads Wonder if you guys will watch the weather channel tomorrow, too. Okay Chill alright God And a story is what he'll like be like, hey, we're watching Thanks Max Meyer and Joe Ryan. I just went there for the twins. Oh, they still will be for sure How's that? Wouldn't you like to know weather boy? It's up Matthew what you got what you got a dad jokes of pac-fired manual Valdes Gunner Green and Miguel Amaya Riley Green and Jeter Downs RPA for the Red Sox 16 of 50. Where are your parents? We're seeing that clip the guys like always talking about like it's like a News reporter and he's like interviewing this kid. It's like snot nose like preteen and he was like Sorry like these fireworks are really fun Like what's your favorite part about the fair and the kid goes, wouldn't you like to know weather boy?  I want to say right yeah right now. Yeah, like a tops update hobby pack.  Yeah, you'll get something for sure 18 to go if I get the whole case now everybody That's awesome and 18 on the second has to work O'Neill cruise red Anthony Rendon color match to 75 for the angels and Jordan one Freeman and another Corbin Carroll to 75. There we go, Arizona Justin W Killing it man. Let's go. How about our good buddy? Doug are with a spot in mega dual case down to 17. Thank you, dog Good stuff. Doug. Thank you, buddy 17 to go on mega dual case 17 to go on mega dual case appreciate you buddy Where's all the neck? Yeah, that's what I'll do Got me illegal. I think are numbered to 249 I would assume so. Yeah, that sounds right. Thank you Charlie pick up the Seahawks in both certifies. I Think it depends. I think some of the base non rookies are either to 249 through 99 Yeah, I think it's dependent on the player like all the rookies are to 249. That makes sense Well, he had a bulletin said he had a Volpe it was a redemption. I'm assuming. Yeah, it'll be it'll be numbered to 249 This is a parallel on it. Does it say a parallel Matt McLean? That is a hobby bias 275 in your canal burns Alec Thomas and Oswald for as a silver signatures to 99 Congrats Yankees nice one there. New York green Manoa and Edward Julian Let's go DJ.  Is that you with the angst? I'm assuming. Yes, it is Drawing Carnation Bryson Stott to 249. Yeah, no problem like Nice one there Philly's Bryson Stott and last box of the break. I love your buddy. Oh in the case Let's go DJ good stuff. Go DJ We got redemption redemption Aroni Oswald Paraza gold Schmidt and Yuri Perez Waldo Cabrera von Grissom nice one there to 249 And we've got Masataka Yoshida base rookie and emerging stars autograph for the Red Sox congrats Boston going to Evan L Good stuff Evan Hell yeah, congrats Evan. Mr. Yoshida right behind you dog Come about a PT cruiser Come about time. Tell me. Tell me. Tell me. Tell me about a PT cruiser. All right recap. We've got a Yoshida Joe Ryan Bryson Stott von Grissom Oscar Gonzalez Jordan Groeschens Dylan Cease Oswald Paraza Alec Burleson Jordan Diaz join a bride George Kirby Jeter Downs Zika Litaran Brett Beatty and Michael Stefanik. They made it better true, I Think you're gonna say they've ruined it, but they made it better to Corbin Carol autos one to 125 one to 75 Rats on that and a Joey Weimer on the first milestones game used base from his first career base hit on April 1st 2023 high April fools. He didn't get it that day. Gotcha. That'll do it for the break everybody Thanks again for the fill coming up next is the first inception and museum mix


This study investigated the effectiveness of various digital filters in reducing noise in electrocardiography, ECG, signals. The study used six different types of digital filters, including Butterworth, ChibuChef I, ChibuChef II, and Elliptic filters. The study found that the Butterworth filter produced the best results, with the highest suppression of noise at frequencies around 0.5 Hz and 100 Hz. This article was authored by Iduaget Hariwesana, Prayambadakayanobrah, and Rizki Ali-Arrakman.


Today, you're going to learn how to use BE used to and GET used to. This is a lesson that was requested by one of my awesome students and I'm happy to make it for you. Of course, I'm Jennifer from jforisenglish.com and this channel is dedicated to helping you sound like a fluent, confident, natural English speaker. Now, before we go any further, make sure you subscribe and hit that bell icon so you're notified every time I post a new lesson. Now, let's dive in with this video. Today, you're going to learn how to use BE used to and GET used to. These are must-know expressions for your vocabulary. Now, both of them are used to talk about a feeling of comfort when something's new in your daily routine. Okay? So let me give you an example. If you watched my video yesterday, you'll know that I'm using a new mouse for my computer. Now, this mouse is a little bit different, a little bit weird because I have to use my thumb to move the mouse, which is not normal, right? So because of that, because it's not the normal way to use a mouse, I'm not comfortable with this action right now. Okay? So I have to get used to it. I have to get used to it. Notice I said used to it. It can be two things. It can be the mouse. I have to get used to the mouse, my new mouse perhaps. So we can have get used to and then a noun. Now, I could also say I have to get used to using it, using it. Now, what do you notice there? In that case, I'm using a verb, but I'm using a jaren verb, a verb in ing. Get used to using. So get used to plus jaren. Now, this is the case for both be used to and get used to. After two, you can have a noun or a jaren verb. So pay attention to that structure. Now remember I said I have to get used to this mouse. This means I have to move from a feeling of discomfort to comfort. And the only reason why is because this is a new item in my daily routine. So anytime you add something new to your daily routine, you can use this expression get used to. Okay? Now, how about be used to? When do we use that? Well, you simply need to know the difference between get and be. So we use get when we're talking about a transition, a transition from not to. In this case, not comfortable to comfortable. Okay, the transition. So I said I have to, it's a requirement, I have to get used to using this new mouse. So I have to transition from not comfortable to comfortable. Now, how about a month later, you could ask me, Oh, hey, Jennifer, how's the new mouse? Is it still uncomfortable? And then I could reply a month later, a month after using this mouse every day, I could say, no, I'm used to it. I'm used to it. And remember that it can be I'm used to the mouse, or I'm used to using verb and ing, I'm used to using it. So here notice I use the verb to be, and that's because I'm talking about my current state. Right now, a month into the future, right now, I'm comfortable with using this mouse. So when you get to the point where that new at item in your daily routine is now comfortable, you can use be, I'm used to it, I'm used to it. But when you're in that transition, you'll use get, I'm getting used to it, I need to get used to it. Remember, get and be our verb. So you need to conjugate them with the time, rest, friends and the subject as well. So if it were she, it would be she is used to it, or she's getting used to it. So don't forget that verb conjugation. So just remember that we use be and get used to when we're talking about something new in our daily routine, and a feeling of comfort with that new activity, we use get to talk about the transition from not comfortable to comfortable, and we use be to talk about the current state as comfortable. Of course, these are both verbs, so you need to conjugate them with the subject and the time reference. And don't forget our structure. After two, we can have either a noun or a jaren verb. So that's everything you need to know to feel comfortable and confident using be and get used to. Now, of course, is your turn to practice. I want you to think about something new in your daily routine. For me, it was using my mouse. So what about you? And talk about how you're getting used to it, and then talk about how you are used to it. So see if you can use be and get to talk about this new item in your daily routine, and leave your examples in the comments below. If you found this video helpful, please hit the like button, share it with your friends, and of course, subscribe. Now before you go, make sure you head on over to my website, jforistenglish.com, and download your free speaking guide. In this guide, I share six tips on how to speak English fluently and confidently. And until next time, happy studying. Awesome job adding these really natural expressions to your vocabulary. You're going to use them all the time. And make sure you get that structure as well. So leave your examples in the comments below and I can't wait to see you in my next video. Bye.


I'm very happy to be able to announce you, to welcome you for our next talk, Matrix, the current status and year-to-day by Ben Parson. Thanks to the internet, the means of communication have evolved in the last year very quickly. In the last years, we started with mailboxes, some of you might remember. Then there was IOC and Jabba and now we have a whole bunch of messengers installed on our smartphones. Each of them has their own advantages and disadvantages. Today, Ben will tell us about Matrix, an open standard, and he will tell us why they saw the need for the standard and he will tell us how they implemented it. So please welcome Ben with a big round of applause. Ben, the stage is yours. Hi everybody, welcome. So I'm going to tell you about Matrix. Before we talk too much about this, I just want to get a quick show of hands. Can you tell me who has heard of Matrix before? Wow, that is probably everybody. Who has used Matrix? Yeah, it's slightly less. And who has used Matrix and they've never heard of it? Okay. So I don't think it's anybody, but in fact it's not as bizarre as it seems because the state of the bridge is today means that you could be using Matrix without knowing it. I'll talk more about that in the future. I'm going to go quite fast then over what exactly is Matrix because I think the most of you already will understand this very well. So it's an open standard for interoperable, decentralized, real-time communication. What do we mean by these things? It's interoperable. It's an open standard, which means that you can connect different parts to it. You can connect different modules. You can connect to other outside services, including proprietary services that wouldn't otherwise make it easy to do so. We do this because we're transmitting open standards. We're transmitting JSON over HTTP. It's decentralized. It's not peer-to-peer. You connect to a single server. That server connects to a federation of other servers. You don't connect to your friend server. It's real-time. It's not like email. It's a push and it's an on-demand service. We provide standard HTTP API for publishing and subscribing in real-time, which means it can be used to power instant messaging, VoIP, WebRTC signaling, IoT communication, and anything else that would have been good to transmit over JSON, over HTTP. Distributed architecture. So we've touched on this a little bit. You will only, with your client, connect to a single server at a time. These servers will then communicate between themselves. You will not connect to other servers. The advantage of this, which we'll see now, is that in a world where there's fragmentation of instant messaging, you've got many different services. They're all incompatible with each other. You've got friends on Telegram, some nerd friends on IRC, and you've got people all over the place on different services. How do you connect to them? With Matrix, because of the architecture design, a home server sends matrix messages between it, but a bridge, which can go between a home server and an outside service, with this, you can send matrix messages, and a user on the other end doesn't even need to know that there's anything happening. Very secure and privacy-focused. No single party owns your conversations. The log of all the history is shared between all participants on each participating home server. Not going to get into a lot of detail with this, but end-to-end encryption is essential in a distributed environment. What this means is that the encryption is performed on the sending client, and decryption is performed on the receiving client. No server in the process sees the unencrypted data during transit. We have a new double-ratchet implementation called OM. This was assessed in 2016, and the results are public and they're very interesting for people familiar with cryptography. End-to-end encryption presents a UX challenge. We must turn it on by default. This is the next step. We need to be able to cross-sign device keys. This means that if you have multiple devices, you have a separate key for each conversation for each device. This turns into a lot of keys, and we must improve the UX for this. This is something that we'll talk about later, and it's been improved over the last year. So I know you all know it. I'm going to go really quickly through exactly how it's used. Sending a message is really this simple. So you send a single JSON object over a REST API, and it contains the correct room ID where you'll be sending the message. Rooms are analogous to channels in IRC. And if you compare the previous slide to this, you can see that sending structured data is very easy, because the message content itself is simply a JSON object, which we will be sending over REST. That means that if you need to send fields or predefined data, you can send that over matrix with no changes to the protocol. So the server-server API, this is the mechanism by which the servers synchronize data between themselves. This is the essence of federation, really, is keeping these servers in synchronization. They can also do what we call backfill, which means that they take historical data and fill in the missing gaps in their own history logs. And they can do identity processes. Application services, very interesting. They enable bridges and other similar tools. The API is similar to the client-server API, but it has privileged access on the server. This means that you can have a user. It's like a virtual user. It's coming from another location. Maybe it's coming from Telegram, but to the matrix user, it looks like a real user. So 2018 was berserk. It was a very, very busy year for the matrix ecosystem. I hope you've been following along, but we'll go through some details now. The goals from the beginning were to finish the first version of the specification. This is what we call R0, revision 0, and it will represent a baseline for what the specification looks like. We'll talk more about this, but there's been huge progress on this this year. As part of this, getting the reference implementations to look exactly like the published specification is an essential goal, and we'll talk about that too. And then we can do a huge marketing push. Once all these things are done, we can say, yes, this is V1.0. This is a version which we think is a stable baseline, and we'd like you to start building on top of it. Many things happened. The adoption rate for this year has been tremendous. It's been larger than we expected. On a global scale, it's large. As a result, time has been spent on improving the performance of the most popular home server, which is matrix.org. And many improvements have been made to the performance there. There's no longer delays in sending messages and such. Home server hosting. This is a new product coming from New Vector, from the company behind Matrix. This is Modular. Modular is, we've been calling it Matrix as a SAS, but I wonder if that's MAS or MAS SAS. So some internal users, we have Web3 Foundation are using it as their main communications platform, and there are other people to be announced. Right now, the server size starts fairly large, so we need to make that smaller. And custom DNS is coming. Actually, migration path for existing home servers is already being tested. So that is available on Modular.am. If you are running a home server on a domain and you'd like to have somebody else host it, then this is an ideal thing. Bridges. What a topic this is. There are so many bridges. Part of the problem with the ecosystem today is that there are 100 different ways of communicating. And while this is wonderful, having some consistency is really helpful. So this is a sort of zoomed in diagram from what we saw earlier. Notice how structurally the bridge, it looks in the diagram like a home server. It pretends to be this in order to be able to communicate back to the other home servers. Node.js is a very popular stack for this. Of course, there's no reason for it to be Node.js. There's no reason it has to be Node.js, but it is the most popular baseline for the stack. So IRC. IRC is probably the most popular bridge. In terms of the users of Matrix, IRC was a hugely popular platform before. Performance issues in the past are, I'd like to say in the past, right now, IRC performance bridging to matrix.org is extremely fast. We have somebody working full-time on bridges, and a huge amount of his time has been spent this year improving this performance. Stability, no more mastery joins, and a new feature replies supported natively on the matrix side. LibPurple. So this is a brand new library, started from scratch this year, created to support protocols available through LibPurple. Of course, the number of protocols through LibPurple is itself a lot. So this enables a whole new world of bridging. Oops, hello. Discord bridge, new maintainer, many fixes for performance. Discord is, we're seeing a lot of people who want to use Matrix who are currently using Discord. We're finding that it's a major place where people are moving away from their current product. And yeah, we've seen a big uptick in usage of the bridge this year. It's now at version 0.3. Slack, Slack has been again updated, well, rewritten with a new version that uses event bridging. This is using Slack's own APIs. And if you're hosting this on riot.im, then it is a single click. It is just a case of adding your room. The bridging is instant and message passing is instantaneous. Gitter, I don't have the specifics, but huge amounts of performance improvements this year. XMPP, this is the big one of the weekend. So this is a real thing now. XMPP is being bridged live. There is a live XMP muck running at, well, you've got the address there. We have, this has been developed pretty much at the assembly where we've been sat for the last three days. And yeah, huge thanks for the XMPP folk for getting involved and giving advice on the setup of the server. And please come and chat to us if you're using XMPP and are interested in bridging this. I know that that's been a huge thing. Still more, there are many bridges. Some of the notable ones that people are getting a lot of benefit from. WhatsApp, brand new this year using their API. Mastodon bridging and still more. I'd love to list a lot more, but there are many. I recommend checking out matrix.org or coming to chat to us at the assembly. Foundation, this is a brand new community interest company set up in the UK. This is designed to separate concerns between the consultancy work which is being done by the creators of matrix and the ownership and stewardship of the matrix protocol. This was set up this year and it's still in progress in certain things. So the transfer of property and the articles of association, I think the articles of association are done or certainly progressed. International property is in the process of being transferred. I know that this was a huge topic for some people. Yeah, and I hope that it puts to rest any concerns about the conflict of interest in stewardship of the matrix protocol. Oh, specification. So this is sort of the big one. This is the elephant in the room. It takes up so much time to write a specification in public for something which is going to be used for many different use cases and implemented by people who have all kinds of ideas about how things should work. Spec progress. This was a known bottleneck for the adoption. We have a single home server. This is matrix. This is Synapse. But what we'd like to see is an ecosystem of more home servers in the same way that we experience an ecosystem of clients today. There are other home servers in production, including Dendrite, but we'd like to see more from the community. And we would think that once we have a version of this available, then we should see more. Federation API. So this is the server to server API that's expected in January, but client server API, very stable, lots of clients in use, lots of work already being done on this. Application service API. So this is for Brots and Bridges, also already ready. And I think this link will take you to the public project where we are watching all the issues related to the spec slowly move from the left of the screen to the right of the screen. As more progress gets done, it's just a terrific amount of work. And actually, this is even an old image that I haven't updated. Progress on Synapse. What time am I? Sorry. Synapse is the reference implementation of matrix. It is written in Python and it represents 99 plus percent of active home servers. It gets regular incremental performance and security improvements. And this has over the last year led to a big increase in performance on matrix.org. There's no longer problems with message sending times. It's much less resource hungry than it ever has been. And the installation and maintenance is improved. Lots of work has been done by the community in providing Docker and Ansible methodologies to install. There's never been a better time to install Synapse, even of course I would say that. It's also now available in Python 3. This is the default installation method. So yeah, that's in itself as given big improvements. Riot. Riot, I'm sure you know, Riot is the most popular client. It also serves as a reference implementation for what the client server API can do. However, the current design is not always attractive. We get a lot of complaints about the UX. In particular, people seem fixated with the problems with the colors. Apparently they're not right. This will be improved. People, yeah, so people have very strong opinions about messaging software. And one thing that we kept coming back to was people like the design of Slack. It's functional, it's simple. People like that. Yeah, let's just pay attention to what they're doing. It seems to be a good UX. So Riot will be the flagship, Riot is and will be the flagship glossy client. It will represent the most complete implementation of the client API. And other clients will be available to taste. Big progress with this redesign on the web. If you check out riot.im slash experimental or if you're deploying your own Riot, just check out the experimental branch. This is a dangerous thing to be doing on your own server, checking out an experimental branch, but this is available now and it's very stable. Looks great, looks much better, looks much more clean, much more accessible for less technical users. People who want just something that's gonna be streamlined and work and improvements on Android and iOS as well. Ooh. Yeah, UX of key signing. This is a real problem because, as we will have heard before, if you have great end-to-end encryption, that's good, but you need to be able to do that for multiple devices. Riot enables this, but if you have to move keys between devices and you're expecting people to compare long hex strings, users will eventually get used to just clicking okay to everything, which does more harm than good. We will improve the UX on this and you should look for this in Riot soon. I don't have a slide of this, but you should see the results of this research soon. Riot, brand new Android SDK. So this is gonna be written in Kotlin, no more Java. It's a re-implementation of Riot using the new SDK. Some of you may have seen the APKs floating around. I've been using it and it is super fast. It's so fast to do everything, especially syncing other projects from this year. So, new work with the French government. So, Dinsik, I took out the meaning of the abbreviation because it was a slide on its own. It's a very long phrase and I don't speak any French, but they are deploying a private federation of Matrix Home Service. What we found in terms of scaled rollout for this product is decentralized organizations, they like decentralization in their software and in their software architecture. What we find is that different departments have different ideas about how things should be configured, different ideas, different departments don't necessarily get along with each other, talk to each other. So, government and academia really get the benefit of a decentralized architecture in these times. They can have different settings for everything, even security, antivirus severity. So, they've developed their own fork of Riot. It's now available to them on iOS, Android and web. They are live and we're expecting them to roll out faster next year. Client ecosystem explosion. So, I think it's fair to say that it's been a very good year for the client ecosystem. There's been a huge number of new clients built. We've also seen feature completeness improving on a lot of different clients. So, yeah, it's fantastic how many people want to get involved and want to make new clients. In particular, you know, you get the competition between who's using QT, who's using GTK, who's using a web thing, who doesn't want to be using Electron, almost everybody. So, there's a lot of different ideas about how clients should be implemented. And as much as it's important to get the UX for Riot, right, it's also important to remember that people want their own clients. They want to be able to do their own things. So, Caternion is written in QT, looks like a QT app. However, the creator is also the creator of LibQ Matrix Client, which supports many projects, including Spectral, which is great. This is the kind of thing that an open source ecosystem can power. We take the library from a previous client and use it to power a much better looking new client. This enables the developers of Spectral to focus on things that matter to them, which is UX. And it works great. C-Glass, native Mac OS clients. So, it's really important sometimes to give people a native client for their platform. Maybe Mac OS is not the most popular for this crowd, but it's really important to have all the features available to people who want them. It's also got E2E support, which is quite early in the development process for them. Fractal, whatever the QT guys have, the GTK guys have to have. So, if you're using GNOME, then there's a GTK Rust client. Huge, fantastic community. I mean, I've said rapidly evolving strong community. It's really, really friendly. These guys, they're meeting, they're going on hackathons, they're making really fast progress. They're even having some really interesting ideas about how the future of messaging client design should be. And they're also providing a new library for end-to-end encryption, which is pure Rust. So this is going to be really helpful. They are also going to be deployed on the new Purism phone, which I gather is this year's product. Yeah, that's, if you've pre-ordered that, then you'll get a copy of Fractal running on there, and you'll have a Matrix client. GOMUX, it's always useful to have a command line application. So if you're doing logging, or even if you just want to sit and have just a command line open, for any other reason, it's super helpful to have a terminal client. I also love with Go just how easy deployment is. Just go get GOMUX, and you're running with one command. It's super helpful. Fluffy Chat. So this, again, strong communities. There's two clients for Ubuntu Touch, which is impressive for the relative size of the ecosystem. And Fluffy Chat is a great-looking and productive environment. They are in the process of implementing E2E right now as well. Still more. My goodness, there's a lot. So, GOMUX using JavaFX. Of course, there's an inevitable Emacs client, Matrix client EL. It's gonna be there. Simple Matrix, a new from-scratch client in Android. This is using no libraries from Riot. This is using purely a Matrix API wrapper written in Java. So, this is really exciting to see competition in that market. I only found out this week about Scala, which is a new web app in Elm. And yeah, and there's more. It's just the mature stuff. What else we got? Summer of Code. Google sponsored, well, Google incredible amount of sponsorship. But they sponsored two students working with the core team. One added E2E bindings for the Python SDK, which means that anything, any client side application, which is built off the back of Python, is gonna get the benefit of those once they're integrated. Another brought Dendrite back to, well, brought Dendrite back and is now on track for real software development. So, we should see Dendrite's progress in 2019. If you don't know, Dendrite is a new server written in Go. It's the next generation home server to go alongside Synapse. The GNOME project had two students working on Fractal. As I say, Fractal, just phenomenal progress in 2018. Lazy loading. Sinking initially can be difficult and it can be expensive because you're downloading a terrific amount of room state to go set up your initial state. The list of members, if it's more than a few thousand, well, that can be potentially huge. This can easily be solved. Pagination of the member list and yeah, what we've seen is an initial RAM usage in riots around 6x, which makes, it makes massive improvements for anybody using a large account. State resolution. State resolution is phenomenally complicated as a mathematical topic and I don't even pretend to get into it. However, there is a new algorithm designed to solve previous problems with this. The view of the state should be consistent across all servers. It's a simple thing to say, but it's the fundamental part of Federation which many, many projects will struggle with. If there's a fork, the state has to be resolved from two conflicting points of view. This is exactly what the new state resolution algorithms are designed to do. What's next? There's a lot been done. Most of this will still be continuing, but what else have we got? Dendrites. This is the Go server. Aggregations to be added to the spec. This will allow reactions, you know, as you see in things like, I say I don't even know, iMessage, I guess Facebook Messenger does it as well, and editable messages. So aggregations are, everything in Matrix is an ongoing list of events. Aggregations will allow you to refer back to previous events and make edits to them. Threading. So this is something, again, people want the features that Slack and other proprietary products provide. Threading can enable this. Decentralized, so nomadic identity. If you've got multiple accounts on different home servers, you need to be able to merge those. And device cross-signing, yeah, device cross-signing can't come soon enough. Oh, what's next? So, thank you. Sorry. Faster. So, now we come to the Q&A. So there was a lot of input, but we have the chance to even ask more questions for everything which is missing on the slides. If you want to ask a question, please come to our mics. I see the first people are already there. For those in the mics, two important information. A question is in generally one sentence long and has a question mark on the end. Second, if you speak into a mic, speak closely to it. Not like that. Oh, we won't hear you. Like you didn't hear me now. And for everybody who wants to leave because they have to go somewhere, please do this really, really quietly. Thank you very much. So, we'll start with microphone number two here in the middle. Hello, thanks you very much for the talk. Yeah, I have one question for the authentication to the servers. If I, yeah, choose one public server, authenticate with this. And for some reason, this server vanishes. So, I can't reach it anymore. No one can talk to me. Is there the idea that I might use a different public server and authenticate via third party? Yeah, so, I mean, this would be, this would be part of decentralized identity. What you're describing right now, it would be like you losing your email address. It would be quite fundamental. The problem that we face in order to solve this is we must first have a way of linking two matrix accounts or possibly third party IDs from other sources in a way that is reliably agreed about across the entire federation. So, it is something that is in mind. It is not something that has been specced. I should say that we have a new spec proposal process, which is something that's been developed this summer. So, I recommend that if you have ideas and a need for that particular use case, then making a new proposal, even if it's just a request for doing that, that would be the way to do it. It's in mind, but I don't think it's been specced out yet. Okay, the next question we take from the internet. Oh, yeah, there are already a lot of questions, many about the cryptography, and there's one question which is talking about bridging. So, basically, how is bridging working? For example, if you have encryption and then you have a bridge to IRC, is there any compromise? So, yeah, at any point with bridging, if you are, let's, yeah, IRC, at the point where you send out the data to be received by the IRC server, no, it would not be, yeah, within the network, it is end-to-end encrypted. Outside of that, then no. So, I hope that's clear. Next question, microphone number four. Hi, thanks for the talk. Where can we find information about the state resolution algorithm you stated earlier? So, I recommend, probably the fastest and easiest way is to go back through the blog. There has been some discussions about it on the blog. If not, we should be linking it from the docs page, but please find me, because if you can't find it on the blog on matrix.org, then we should link to it better. Awesome, thank you. Microphone number three. Hi, yeah, thank you very much. Do you plan on improving usage of proxies or especially Tor with Riot? Because at the moment, there are a lot of problems. For example, there's no UI for proxy configuration. You have to do it via parameters in the command line. And I tried on Windows. It doesn't work. It uses ClearNet. And also, Riot leaks DNS when you do VoIP calls over proxies. Do you plan on improving that? So in general, the short answer is we plan on improving a lot of the configuration of Riot, because as you say, most of it is command line switches at the very beginning. I'm sorry to say that I don't have visibility on exactly the specific features of Riot. I recommend joining the Riot Dev channel to talk about that. I'm sorry for not having more information. But in short, configuration options are something which need to get more attention. Next question from microphone number two. So this year, I've heard that the IETF has been working on the whole messaging layer security working group thing. And I've heard that the matrix team is pretty heavily involved with that. Could you speak to that at all? I'm not sure what's been done with that. It's a fun working group. They're doing a lot of federation stuff with a bunch of different messaging systems. This is related to activity problems. It's a lot of end-to-end kind of stuff. But yeah, I don't know. Sorry. I've heard matrix people are involved with it somehow. Not my knowledge. OK, come afterwards. I'm sorry for not having more information on that. OK, we have another question from the internet. Yes. One user asks, what's the best way to get into Matrix for Emacs users currently? The best way to get into Matrix for Emacs users currently is to use matrixclient.el. The Emacs community is rabid and excitable and gave me a crash course in using Emacs when I needed to figure out how their client implementation worked. So friendly guys, but rather religious. OK, microphone number two. I've been using the ERC gateway with Hackint. And I noticed the speed improvements that did seem to get much better. But Hackint is shutting down their gateway at the end of the year. And they're also saying that we should not use the main matrix gateway. And they have some, I think, three specific reasons. I wonder if it sounds from your nod, like maybe you've heard of this, maybe you could address some of their reasons of what's coming. So I don't know about the three, but the two reasons that I understood were performance in general, which I think we've spoken to. And it has improved. But I know that the frustrations that they had were very real. The other concern that they have is something which is now is beginning to be specced, but was not at the time when they had their complaints. And that relates to customizable message retention. One of the features of Matrix is that the whole history of forever is potentially stored. This is something that they were not happy about. It's a fundamental part of the specification. However, it can be changed so that we can add customizable per message or per room or per custom level retention policies. Of course, this is difficult over Federation because you have to trust what is being done on the next server. But if you are able to do that, then you can have custom retention policies. So yeah, I would love to see Hackint back bridging with Matrix. Microphone number one. You seem to be happy about having a huge... Speak a bit closer to the mic, please. You're having a big ecosystem of clients. Will it be possible for clients to implement features that only work with a specific client? Is it something you want to have or...? So yeah, this is an interesting one. So the question was we're very pleased at the number of new clients and the number of new things that are coming out. I think your point, really, is that they're all essentially chat clients. They all have that functionality. Would we be happy to see use of custom fields in order to enable different client ideas? And absolutely. So there's actually a few examples of that already. So we have people who've made blog engines built on Matrix using custom fields. People who've used... They've made slides. So you type into a matrix room and it produces a slideshow from this. Yeah, absolutely. You could do different things with different clients. It's just a view onto a room, a client. And it's simplest. So yeah, having custom fields is a big part of it. Being able to send structured data, yeah, it's half the value. So yeah. Microphone number two. Hi, thank you. How is the governance structured for the new matrix.org foundation? And how do you ensure a variety of voices in there that are not the originating team? Right. So I mean, one of the simplest ways to do this is to get people who are not in the community and are not part of the team into the governance structure. So there's a board of what they're calling Guardians. This is people who pledge to protect the spec and to keep it free of commercial interests and make sure that it's a neutral communications protocol. In terms of the specifics of the legal stuff, I strongly recommend checking out the substantial blog posts that have been posted about this because they should clarify, yeah, a lot of specific points. If you had other specifics, then maybe I could speak to it, but it's a lot of legal detail that is quite well covered, in my opinion. Microphone number three. Since I'm currently in the process of developing an iOS client, I very much would love to hear more details about how you plan to improve the encryption UX because currently that's horrible and we're struggling ourselves. Okay, yeah, it's a huge challenge. Yeah, that's great that you're developing a new iOS client. Yeah, that's really cool. I'd love to know what APIs from Apple you'll be using for that because I know that they focus a lot more on iOS than on Mac OS, which has been a problem for the C-Glass team. Yeah, so one of the things is comparing images or comparing shorter strings. The other option would be to have incremental backup of keys, but we haven't actually released any designs around that yet, so please contact me and just tell me more about your iOS client, that would be really useful. We can talk personally later. Yeah, I think so. I'll stay around. Thank you. Okay, we have time perhaps for one or two more questions, so microphone number one. Hi, thanks for your talk. We talked a lot about chatting. Do you know if there's other kind of applications running over metrics? Yeah, I mean, so there are sample bridges for all kinds of different things, including some microcontrollers. I've also built a yet to be released sort of demo for Mozilla's Internet of Things gateway. So yeah, there are different things out there. As I say, there's software for making blog posts, there's software for, you know, master don bridging is not strictly, it's not strictly chat, I suppose. So yeah, I'm not sure how many examples there are, but there's nothing stopping anybody who needs to transmit structured JSON using it for anything else. Messaging is just the most obvious thing. Thank you. Okay, time's up. I'm sorry for those who still have questions. You can just come up afterwards and perhaps talk to him in person. And yeah, let's finish this with a big round of applause for Ben.


8% comes from the fact that 92% of insurance agents fell in their first three years. Well, what does 8% mean to you knowing that statistic? Well, it's sort of like any kind of a skill. The skill of selling is like the skill of typing. It's like the skill of riding a bicycle. It's a learnable skill. And it's something that you can learn through continuous practice. And a lot of people don't understand that. And when I started off in selling and knocking on doors and knocking on doors and after six months, I was just still struggling. And there was one guy at our office that I told this story. His name was Pete and I still see his face after all these years. And Pete was selling 10 times as much as anybody else in the company. We had about 15 people. And I would start working at seven or eight in the morning knocking on doors. And Pete would start at nine or 10 o'clock and he would take time off for lunch and he would quit at 4.30 or five. And he just had a great life. He earned more money than anybody else. And one day I asked him, I said, Pete, why is it that you earn so much more than I do? And he said, well, show me your sales presentation and I'll critique it for you. And I said, geez, I don't have a sales presentation. I had heard about a sales presentation. I sometimes joke and I say, it was like something on the other side of the moon is I knew that there was a sales presentation out there but I'd never seen one. And I said, well, I don't have a presentation. He said, well, what do you do when you get face to face with a prospective customer? And I said, oh, I just, I tell him how good our product is and how helpful it is and how much it's better than anybody else and everything. And he said, no, no, I remember. I remember this, we had an office in this office building, third floor, and we went downstairs and across the street and we're sitting on a park bench, this big city park, a city park. And he said, that's not how you sell. What you do is you don't talk, you ask questions. And I said, ask questions because I was told you have the gift of the gab. You know, you can talk really well. And he said, no, no, no, no, ask questions and listen closely to the answers. And over the years I found is that your ability to ask questions and listen to the answers in a positive way is really the key to successful selling. And a good friend of mine, one of my best friends now, top sales guy, he said, remember listening builds trust. Listening builds trust. Well, how do you get a chance to listen? Well, when you ask questions, you ask good questions and you lean forward, you lean into the question. And when you listen closely, people warm up to you and listening builds trust. And the more you listen, the more they trust you and the more they like you and the more they're open to being influenced by you. And I still remember those or some of the most important things is that, wow, listening builds trust. So I asked questions, I just kept asking more questions and what about this and what about that and what are you doing now and how is that working for you? And what are your goals? What are your plans for the future? And it was constantly asking questions, changed my whole life. Instead of trying to persuade or influence people instead, look to them and try to help them. When I do seminars, when I hit the peak, I was doing seminars, my average seminar was 1600 people for more than 20 years. And sometimes it was 2000, 3000, 4,000 with gusts up to 5,000. My biggest seminars were 20,000, 25,000. And it was wonderful and it was so helpful to people. They leaned forward. And in my seminars, one of the things I learned is to ask questions rather than talking and trying to impress people, ask them questions about themselves and what they're doing, what their goals are and so on. And it was just so wonderful. And it's the same thing with you. You are going to be a great speaker in the years ahead. And you'll find that when I start off with the audience, I start off by asking them questions and asking them and follow up questions and more follow up questions. And people love it when you ask them questions and listen because questions encourage them to really think deeply about what it is they're doing. And so I would ask people questions and then I would give them answers and ask more questions and give them more answers and so on. And that's how I got to RIM today. I would ask questions and give answers and tell them how to use the information. So many people I'm happy have become millionaires. My friends at Nightingale Conant did a research study on people who used my materials. They found that more people, more salespeople became millionaires as a result of using my materials than any other single influence. And of course everybody wants to be a millionaire. And yes, you can become a millionaire. And what you do is you do what millionaires do and good millionaires. It's interesting. One of the richest people in the world is Mark Zuckerberg and president of Facebook. And they say he's got a five to one ratio in terms of listening and speaking is that he asks questions five times or every one time that he talks or comments or gives guidance. And it's just an interesting thing. He just continually asks more questions and takes notes and so on. And so it's a very good thing to remember. And I see you taking notes. That's a very smart thing. The most successful people take notes all the time. And it's just what it does is it helps you to think at a deeper level and also to review the material. I'm always astonished. I say, okay, please write this down.  They come to a full day seminar and they don't have a pencil. They don't have a pen that I'm really to write with. I just shake my head. SMH, SMH, shaking my head, shaking my head. It's like, I can't believe that. I can't believe that people would go to a seminar without preparation to write things down. And so that's another thing is make sure that when people come to your seminars is that they are supplied with writing materials and so on. And so I always carry a red pen and a blue pen. And my kids would ask me, dad, do you have a pen? I say, what do you want, red or blue? Red or blue? You know, I've always got two. And one is to underline in red and blue is to make a note. And so my kids now carry pens around and they hear something good. They immediately write it down. Napoleon Hill had this wonderful one liner. He said, and when you think it, ink it. I thought that was really cute. When you think it, ink it. If you have an idea, when an idea goes through your mind like a comet, immediately write it down. Because if you don't, you forget it, you'll lose it. And sometimes you'll have one good idea that can change your life. And if you don't write it down, you'll think, geez, what was that idea? And then you find me, somebody else who had that same idea as well. And sometimes it's just one simple idea that changes your life. One of the things for our friends who are watching is how important it is to take notes and to read. Is to just dedicate yourself to continuous learning. This is, I say that there's three things in my life. And I talk about these three. I call them the golden triangle of success, like a triangle. And when I look back over my life, I realize that there are three great things. Number one is to accept responsibility for your life. Don't complain. Don't make excuses. Don't blame other people for your problems. Always accept responsibility. And number two is to have goals. Clear written goals and plans. And number three is dedicate yourself to continuous learning. Always be learning. You look behind me. I was just reading an article on me that was in YouTube. I wasn't in YouTube, it was on Google. And somebody had done a complete research. It was called 20 Things That You Don't Know About Brian Tracy. Well, I had never seen this before, so I read it. And one of them is that it said Brian Tracy has read more than 7,000 books. And I thought, oh, and yes, that's true. I must have said it somewhere. You see these books, these are all double stacked. So there's two books at every shelf. From the top to the bottom. All you can see is the middle, the bottom, the top. And this is just in my office. And it goes all the way around, but it's also outside. It's in other rooms. It's downstairs. My whole house is just full of books. And I may not have read them all, but I continue to buy and read books. And then sometimes you just come across one idea and you say, Jesus, that's a good idea. Jesus, that's a good idea. And then you have an opportunity. Here's something really interesting. I found that, and I studied metaphysics in my 20s. I came across a Russian school of metaphysics. And what they taught was that you never learn a subject without having very soon an opportunity to learn or to use that new material. As you learn the material and very soon you get a chance to use it. And I thought, well, that's interesting. And for the rest of my life, I realized you read an article on something you find it in a book or a magazine. And very soon afterwards, you have an opportunity to use that material to improve your life or the life of someone else. And so therefore, you must dedicate yourself to lifelong learning. For the rest of you, just always learning. Hey, if you enjoyed this, I got another one. You're gonna love it. It's right there. Click on it. See you in there. Thank you so much. I wanna thank Cody and Lauren for putting this on.  Amazing, amazing event. Okay? Amazing. Really, you guys are awesome. Like when he called and said, hey, would you do this deal? The fact that they're willing to.