 Okay, does the microphone actually come through? Okay, great. Thanks. So thank you, Thor, for giving us a recount of your experience on the game day, and congratulations on being a part of the winning team. That is the exciting part, and I'm literally... I can't find my slides, so... Yeah, we're doing it this way. And I just accept that. Yeah. Yes, and her new bug is definitely on there, so... What's that? Sorry, I got one. Yeah, right. I broke my glasses yesterday, so... Okay, so we start off the game. This is a game scenario, right? So the whole concept of the game itself is to ensure that we have a concept and a part of an idea for people to latch onto. So there's role play. And the concept of the role play is to get up and to just basically be the CFO of a startup, right? So you just walk up and you're like, you guys are all... I don't know if you know it, but you were all fired from your jobs yesterday, and that's why you're here now. And then we give a little bit of information that's associated with the experience. Like, hey, we were running this company really great, but then a couple of things happened. Some people quit, like all of them. And then we've started to get some customer feedback. And the concepts there are to get into the specific quests. Now, a quest has an objective, right? So in this case, what we wanted to do is create a social aspect. You want to make sure that you can generate some sort of common application that can be shopped around to other teams. So if you want a good experience, right? You want to build in that connection, right? So what we do is we build a game. That game is then served out from a... In this case, an instance. We were using Red Hat Enterprise Linux on the Cloudy Hops. And then you're capable of playing the game, but then you're also capable of getting other people to play the game. And when other teams play the game, you get points. So you want to shop around to make sure that happens. And effectively, that gives each one of the team members an opportunity to participate, regardless of the level, right? So the reason you want the social aspect is because you're going to have people who have zero level experience with the products that you're trying to showcase. And you're going to have people who are expert level. And you want to make sure that you've covered the gambit of things that can be associated. So somebody has to choose a more social role. They still can. And that kind of goes along... I mean, in my opinion, that goes along with the sentiment so the way that we handle most things in the open-source community. So you want to make sure everyone stays included. So this one, the Cloudy Hops, this has a modified Flappy Bird in it, by the way, that has a red-hat hat as the Flappy Bird. You might have to be getting into that. Right. That's right. That's right. It doesn't work. That's right. Hence this customer experience, right? So good thing you were there. And then this one, the Goldfish, there was a Rick and Morty Concentration game. So we took the Rick and Morty Concentration game and then rebranded it as a red-hat Concentration game. So we used a lot of red-hat icons to build out the structure for it. The way that those... The way that that, you know, translates is you expose it on the open-ship... I mean, in this case, on a rail box. But the concept is to expose that interface for access and then to make that social experience happen. This game is built on Ansible and Ansible playbooks and centers around the experience of having emerged conflict that you've got to figure out how to resolve in the configuration. There's a team dashboard. The dashboard has all the information and provides the experience. And this is what it looks like. You end up with a hash on that screen that basically takes you to your own console. So once you put the hash in, you get a table number, which is so everybody can use that. Thor said he thought they should use one laptop instead of having two laptops. The one laptop would have the team dashboard on it. But with two laptops, you can have the same team dashboard on two laptops. If you have four players, those four players can do that. And the way that the event engine that we use is established, you can do that with teams that are in different countries effectively, right? So the concept of the game day is not something that is localized. It's something that we can, in fact, bring to all of the members of a team even if they're not geographically located in the same place. When you log in, you end up with access to the quest itself. And since I'm having trouble with my slides, the quest is effectively the part that is the interaction for the players. So we have an event engine that effectively covers the whole thing, right? And then we have multiple accounts for each one of the teams. Each team gets their own account. So for one table, so if you have, you know, one table with four seats and everyone is playing on this table, that's one player account, right? So if you look at that, you would think about it as one AWS account. Now, the event engine has a master account. So this main account here includes all of the requirements for the game. So you would see one cloud, we do this with DevOps, of course. So you get one cloud formation template that deploys the entire infrastructure for the main account. And that main account becomes the command and control for the entire game. And then as a developer, as someone who is developing for the game day, you're building out a cloud formation template that has all the content in it. Now, for our internal games, right, this may, it would probably be more, this would be all that you would do. But for Red Hat, we've determined that there are some things that we can't deploy into the configuration here based on policy requirements. And so instead of just using the team accounts here, we're working with the demo team. And the demo team at Red Hat has provided us the ability to stand up additional customer resources so that as we interface here, right, so this basically is an event loop, right, with a dashboard in it. So the dashboard for the game is exposes the content from the team account to the main account. The main account then can do monitoring, it can do command and control in the association. And then you get back a score. So with all of this, with all, with the way this works, we'll have resources here that are monitoring and managing the game. This is where your event engine is. So as the players make changes to each one of the individual quests, and the quests are actually here deployed in the master, in this main account where the players don't have access. The players have access to all the resources that are down here. This is where you're deploying instances, and you have different kinds of applications running. On top of having the ability to have an OpenShift configuration on this side that's deployed through Agnostic D. And if you haven't seen Agnostic D, this is the tool that the demo team is using to create all of the configurations that they provide through the demo portal. So any of you who are looking to learn about services on Red Hat would probably go to the demo portal. So you'll understand the infrastructure that we're using for the game because it is immediately available. So as someone who wants to build a quest, if you want to build your own Goldy Fish, you would create a template using the development kit. Now the development kit provides you an entire configuration that lives instead of in two accounts, right? Instead of being set up in main and team, it combines the two. So that as you're working, as you're making modifications to the configuration, like let's say you wanted to build out an OpenShift configuration on the demo portal, you build that out, it's successful, you deploy it, you deploy the infrastructure to support connecting to it, right? Like instances that you can use through terminal or through a graphic display. You would then be able to take that entire configuration and deploy it in a single account while you're doing your development process. So what we do is we carry the development process in a single get repository, and then that way we can split out what goes into the main account for control and we can split out what goes into the team account into two different templates. Any questions so far? So one of the other things that we wanted to cover is scoring. In the gameplay, we want to make sure that people are engaged and that the experience is something that makes them feel their progress. So you want to have various stages of scoring. Each one of the opportunities for building score can be greater or lesser. It all depends. They're attached to actions. So if we go back to looking at the quest itself, these quests will have individual components. Like, for example, the first thing you do in the Cloudy Hops game is to identify the endpoint that the game will be served from. So that's identifying what the URI is for that specific server. When you identify what the URI is successfully, you get points. When that URI is identified and the Cloudy Hops know working, then you get no points. So you have to determine exactly what component parts are functional, what are not, and then add hints. So now that I know that my score is greater or lesser based on success, then I can say if I want a score for an endpoint, so you gave me an endpoint, I give you a thousand points. You ask for a hint because you don't know what the endpoint is. I give you negative six. Something like that. This represents a very small, like a basic hint. Incrementally, you know that everybody is going to get a thousand points for the endpoint, but not everybody is going to really realize exactly what needs to happen to get that endpoint in place. So they're going to take one of those little hints, and then maybe they need a bigger hint and a bigger hint. And just that subtraction of, like, the smaller amount of points, you end up with very interesting variations on the scoring. And we saw that yesterday. The first thing, was it you, Thor, who was like, how did we get, no, it was Marcel, who said, how do we get negative points? But it didn't matter. It got a couple million after that. So, and this represents like a first, so, you know, these are first attempts. Game complexity is in the next step in our process, right? Is understanding that you have, if you've achieved one thing, that can't be the end of the game, right? We want this to go on. We want people to feel the experience and the warmth of actual production, right? We don't want them to be able to rest. So, as you build out these quests, we don't. No rest for you. That's right. Well, I mean, if you're going to win the game, come on. Like, if you're going to maintain their attention and the commitment, there has to be some next level. And so, what we do is we build out multiple layers for each one of the individual games. For Cloudy Hopps and Goldy Fish, we don't have as many levels as we would like to have. We're working on that, right? So, love to have your help in doing that. And then, so the complexity means you have to layer in more of the company vision, right? So, a lot of what we do there is, so to add networking complexity, we have a team, a security team. We call Threat Slayer. And we use Threat Slayer for a lot of things. Threat Slayer comes in and actually has to apply policy. And if you've ever worked in a Cloud environment, there's identity access controls. There are firewalls. There are access control lists that are so independent of the expectations of the basic instance. That the hunt can be quite complex in itself. So, we add complexity with our metal band turned security team. And we use other opportunities, natural disasters, complicated action. So, what we would like to have in that process is something, some next level of complexity so that those who are actually achieving at the lower levels can move upwards in that game. We can do a game day for up to 72 hours. So, the more complex, the higher number of quests that we have, the easier it is for us to sustain attention and entertainment value in those 72 hours. It's really helpful to have a goal in mind that is directly associated with a specific service. Cloudy Hops obviously is structured around two things, which is just basic service enablement and SE Linux controls. And then their container-based system has, I'm sorry, the Goldyfish configuration has a goal of building a container-based system that is managed on a rail system, a rail server, with the added complexity of ensuring that you have an Ansible playbook that is fully functional for the process. And building out and running the Ansible is kind of the strongest methodology that we want to pass through on best practices. But that doesn't mean that the winner is going to use that Ansible playbook. And that is kind of one of the other things that I wanted to talk about, is there's a seemingly random pathway to success. And part of building out this game is discovering how people shortcut your practices and then how to score that. So, for us, the idea is to help people along in the context of the best practices. And we know those, they're observable. But that doesn't mean everyone is going to be able, is going to know exactly where to look. We were laughing about this yesterday, is that they're almost everything that we had. If you had gone to the rail documentation, you actually would have found the steps to fix the problem. But nobody went to the documentation. So, as a result, we saw a lot of different things. And we had an interesting debate just by having someone solve a problem in a way that was non-standard. One of the teams literally stood up secondary architecture and wanted to rebuild everything on CentOS Stream 7 and then did a deployment. And so the deployment was effective. It worked, but it didn't score the many points. And the interesting part of that was that this was, because this happens in a cloud environment, one of the principles of building out cloud infrastructure is to remain leaned. So they actually extended, they doubled the infrastructure requirement by standing up a secondary instance. So there was a question about whether or not this was, you know, they had achieved the goal and we sort of stepped back, looked at it from both sides, tried to determine what we thought was right and then just generally agreed that this was an infrastructure mistake. So, and that brings me to the score, like the scoring events themselves are deterministic in the basic way, but then there is some room for us to identify and apply some changes to the point structure just to make sure that if someone is working and they're discouraged or they don't understand, it doesn't stop them from getting some sort of an advance, you know, to feel like they're still part of the game. And this is also a part of the structure and practice around this, is that you have to build some compassion into the experience otherwise you may lose your audience. And lastly, before we just start generally talking about it maybe I can show you some code is the prize structure. So, obviously this is unicorn rentals and unicorn rentals needs to have something that is mildly representative of the unicorn experience, right? So we try to put things together that are glittery and fun and not practical because one of the things that is interesting about the game is the thing that is interesting about the game is the play. And it shouldn't be a competition. It should be something where everyone is excited to participate and everyone is happy when they finish and they don't feel so heavily invested that there's a sense of fairness or complexity in their vision of the game. So we don't want you to feel like you're missing out, right? Which is why we gave a baby unicorn and not a full-size unicorn to the winners this time. We rent them. A lot of times, you know... Yeah, that's right. And that's a point that really made this business what it is today. So the prizes themselves need to be simple and they need to be... they don't need to be heavy investments. And my favorite one... my favorite prize to give out is having your name permanently taped to a plastic unicorn statue. Okay, so with that said, configuration management is really the next step in this and how we get to the configuration management is through what we call the Quest Development Kit. The Quest Development Kit has all the things that go in the main account, right? And that's a bunch of Lambda functions and some serverless configuration stuff that sets up all of the event-driven actions that come down here. So for Fargate, there's a bunch of containerized applications that we use to do this, and we build them out in a serverless infrastructure so that it's fairly efficient. This part is kind of hard-coded. There's not a whole lot that you can change about how the events are structured, but what events are trigger points and how those are evaluated is part of the Quest experience that you would put in this command account. The command account interacts and executes within the context of the player account. So the player account is leveraged for anything that the user is, like, the player is capable of doing. So if you wanted to have... Adam and I have talked about this before. If you wanted to have a full open-build system in the cloud, we would set up the open-build in the team account, and then we would identify actions, notifications that would then trigger points scoring or identification of the unlocking of specific tasks in the Quest until we get to such a point that we feel like that section of the task has been completed. Once that's completed, other things can happen. So a second layer can be activated at a later time. So as you build, you build one, and then you'll build a single action, and then you can build a secondary action and a tertiary action and N number of actions right after that. That can be enabled in succession on that same Quest. Yeah, the sky's the limit. Application space is built in Python, but there is a TypeScript version, so almost all of the work that you're going to do will either be in Python, CloudFormation scripts, Ansible, or TypeScript. Although secondary actions, like if you have something that's functional inside of an application, you can do it from there. Roadmap. So we really enjoyed building out two rail server configurations for the game day, but we are focused on ensuring that we cover the gambit of rail products so that we can make those available to the general... just generally. And we want to start with a modernization component. We have a slot for a Quest at AWS re-invent this year, and we're really looking forward to that. And we want that slot to be filled with an OpenShift configuration. So we are working diligently on building out support for the Corkus Coffee Shop as a component part of the Unicorn Games industry. We are working on the Unicorn Cafe. So the Unicorn Cafe will be our next Quest, and that will include some modernization steps to get an application onto OpenShift using various components of the OpenShift infrastructure, and we'll be using that for... using that to secondarily extend that into space, which is our edge component. So once we have a successful Unicorn Cafe, we'll launch the Unicorn Cafe into space. And we'd love... Sure. Well, so in the early days of the game, that happened a lot. And it is quite possible for us to take that kind of action. So if you're... One of the things that we're doing here is we're creating the social experience, and you can bring that on, and then, in fact, if you've got, like, let's say, from your main account, from your command center, your command center can make determinations based on anything. One team had all... Like, if every other team was using one team as a central source for their game or for whatever action... Like, we've built reverses. So literally, we have, like, applications that are just reversers, right? Like, you just throw a... It just throws a word in, reverses the word, and then provides a hash. And so you get... The response is the hash and the reverse of the word, and the hash gets you points. So if everybody was using the same reverser, right? So if the endpoint came from the same team, then you could probably... You could do something like hit the next level of the game, right? Like, destroy all of their networking, right? And so that is definitely a part of the process. You can make those modifications. So the kit will allow you to do that, and we can do that all in the same... You know, consistently in a single account. In terms of the technology that you can use, because we're connected to the demo team, we can use anything that's in the product suite associated with Braille and OpenShift. And then... And actually, we can extend that all the way up through the IBM suite. So plus everything that's associated with AWS, of course, right? Any secondary service or connected service. We can do that as well. Yeah. Any other questions? Yeah, thanks for being here. Oh, yeah, I understand. Yeah? Have you been using some kind of messaging system? Yeah, well, of course. Inside of Amazon, inside of AWS, the AWS infrastructure, there is a simple notification service. So we use a simple notification service to cross into... to cross from one account to another. And then we use a queuing system to identify... so that if there are messages that we need to carry into another application, we use what we call the simple queue service. And the simple queue service is there for that. And it's also fired off of the... some simple serverless applications. So there's Lambda Functions, and there are container-based workloads that, for larger-scale decisions, were chains of Lambda Functions that, in fact, we'll do... we'll process some of those events in a way that's consistent with the scoreboard and the game and update the databases that are associated. So there's like a bunch of Dynamo... DynamoDB, there's not only SQL configuration here. There's for the dashboard and for the users and for the hash... hash that are associated with the accounts. And that... that is the way that you get... you get support for that continuous feedback. We also have, on this side, we have access to streaming services. So we can use Kafka over here. We can use standard message queue on the demo side. So all of the work that we're doing that is connected to the Red Hat portal is... communicates... communications from here, and then we have an application endpoint. That application endpoint is something that's... it's not shared, right? So this is strictly set for each team. So each team has their own environment that is configured for providing information to them and then also feedback into the main... into the main account. So as you make changes here, we use... we have an API that the... the OpenShift configuration can call and make... and make chain... you know, make updates or changes here. All the basic cruddles. Anything else? Well, I'm excited for anyone to do the work. If you're interested, please drop us an email and we will... we will... get back to you and make sure that you have everything you need in place to work with us on the quest. Yes. So if we... so... yes, we are... we are breaking everything in a way that is consistent with how this works. And a little bit of history there is that Game Day is based on the... the application... the way that we build applications like new services or new region launches. We establish a stress test for Amazon. This is like a basic practice for Amazon is you set up a... well, it's a basic practice for anybody who's deploying a service for themselves. But you stress... we stress test pretty significantly. Test scale, test the application... sustainability and resilience. And then... and then make determinations on what we need to change, right? So whatever you look at what failed you look at what failed and then everything... and then go back to the drawing board and figure out what you need to change in your design. Same thing here. You stand it up. You get other people to use it. Then we will either simulate that there has been a failure based on that stress test or we can... in fact, we may have a stress that like literally kills it, right? You might have an auto scaling group that's too small or something like that and then ultimately you would have to change it if you have enough people hitting your service, right? So as a social... as a social experiment it can also be the thing that causes you to run into your own limitations and then have to make an evaluation on what you're going to do next. That is the... you know, that is the project plan. Now the reason I wanted everybody to come to this talk was because I want them to think... to imagine those possibilities to understand that from the perspective of being someone who develops a game and then takes that back and takes the development kit and provides us something that can fit into the game experience inside of the community based products that are associated with you know, with the Red Hat ecosystem all the way up through all the way up through the more advanced products. We chose to highlight caucus because we think that that's a very good fit for the OpenShift experience and targets some people that we think are a little bit more have a little bit less experience around modernization but really want to have more experience around modernization so we think that they're going to be very excited about the next iteration of our games. I'm glad you had a great time. Any other questions? We can leave it at that then. I have to unmute myself first, right? Yeah, okay. So I'd say let's start. Thanks everyone for coming, given the beautiful weather outside and then it's Sunday and the beautiful weather. Welcome to my presentation with the spicy name, all the things that they didn't teach you at the university. I'm expecting I'll teach you everything you didn't learn at university in 30 minutes otherwise you're in for a let down. So anyway, first the boring part, who am I? I'm Dan Cermak. I'm a software developer working at SUSE. I also do things in the Fedora community and for my interests besides doing things on the computer also working on development tools I'm quite passionate about testing and occasionally when I get to it I write documentation and then break my home automation because I like standing in the dark or implement funky stuff there. If you'd like to stalk me on social media you can find the few links there. I might post some stuff there for example, link to the slides but there will be some later. So now that we are done with the boring part I'd like to maybe share a bit of a history because first I thought first the disclaimer I didn't study computer science so I studied physics that means a lot of the stuff that I learned from my day job I had to teach myself and I thought well I'd like to share a few things that I learned over the years my Unix beard is not that long so I can't I most certainly don't know everything by far but I learned a few things I wanted to share them so I started to write my thoughts down and what I learned over the years and I realized this thing is going to start to grow and grow and grow and it's not going to be a presentation it's going to be like two lectures maybe three, maybe a whole lecture series so let's not do that what I'm going to tell you things like yeah you should test your stuff you should have a proper staging setup but no matter how good your staging setup is you still occasionally will have to go into your production server and just comment out the faulty line and pray that you can get into your production server unless it's some kind of certified super secure hardware and you aren't allowed to touch it behind you and their manager and someone is signing that off with their blood also ugly things like most real infrastructures hold together by duct tape glue, hopes and dreams and a lot of magic but also more positive things like if you want to do today something with computers and with code you'll have to use version control and that means git I mean nothing else is really used in practice if you want to do backend development nowadays you're going to use Python, Node.js, Golang in the front and it's still all javascript web assembly is becoming a thing but it's really not that yeah and if you go into the enterprise world it's going to be Kotlin Java, Java, Java more Java if you're unlucky it's also going to be XML and maybe a bit more Java and you're going to touch SAP whether you like it but well some of this stuff will change some of this won't so I would hope that the infrastructure stuff will change but I'm afraid it won't because it's been like that for 30 years but if you work in open source one thing will really never ever change probably and that's you have to work with people and the interesting and challenging thing with open source and when it comes to people so if you work in a company you also have to work with people but you have the same HR department you're kind of there because you get paid to do your job and if someone doesn't want to cooperate with you you can escalate things or sometimes it helps sometimes it doesn't but there's structures but if you work in open source you're there for your own motivation and the other people they have their very own motivations and they can be completely different to yours maybe you do it for fun they do it to put it on their resume maybe you're doing it because the software doesn't do a thing and the other contributors do it for completely different reasons maybe they just like the community your employers are probably completely different companies maybe a bunch of the contributors do it in a free time and their HR department won't be bothered if you try to file a complaint because they do it in a free time I don't care about our problem maybe there are no different continents and even if you do it in your day job doesn't concern them people work from all over the world and you have completely different cultures which can be a great challenge when it comes to communication and also one thing that you really shouldn't underestimate is time zones I mean most of us probably are sitting in zoom teams, jitsie whatever calls all day and you know the trouble of time zones but this can be a huge problem for open source projects if you are suddenly if suddenly all the contributors are sitting in North America if you are in Europe or in Asia and they decide stuff in a meeting and for you it's 3 a.m. or it's 12 and you are at your job and you just can't join a call for your free time project in the middle of your working day and you have people in volunteering positions maybe they get paid maybe you have outside contributors who get paid you do this in your free time and they tell you hey fix this bug for me no I'm not going to give you money, sorry maybe you have students and this all makes open source much more challenging than really close source development where you just have corporate structures which may or may not provide you with some backing maybe not but so that's really I'd say the most challenging part of open source I mean you can also just make your project open and not accept any contributions at all technically that's most certainly open that's open source to the letter but in my opinion it misses out the one big thing and that's the community so your open source project usually has some kind of community behind it and for many projects a community is really it's just a bunch of people that work together on a common goal that they share usually it's just keeping this project around and for many open source projects you just become part of it by showing up because there's no clear onboarding process I know there's there's project nowadays that have welcome channels and you can get and they try to onboard you in very friendly ways which is definitely a good thing but I know the first open source projects that I joined I just came there started fixing bugs and eventually they told me far quicker than I was comfortable with hey yeah why don't you get merge rights you sure about that but yeah so the point of the community is to have a common goal and really to empower others to work on this shared goal and since we're dealing here with people the big question is always how do you communicate with people so you got always you got your multiple options you can have your asynchronous communication forms where you have your mailing lists we all love them don't we forums but then also more synchronous ones like a simple chat so maybe slack maybe discord maybe you're still on IRC or matrix or voice chat but these really serve completely different purposes so my recommendation is if you are building up your open source project or you are participating in one you should have one of each don't have five different places because people will land in the wrong one at least someone will so really just have one also issue trackers bug trackers etc nowadays that's mostly github but there's also other things for that hopefully not JIRA if it's JIRA for your open source project I don't envy you but you do you and as I said have really one place for everything so have one chat if you want to do voice chat and video chats you can do that but really take into account that people come from very different backgrounds they come from very different time zones if you want to do voice chats you might run into people who are sitting some who are sitting in the rural area and the internet connection is really bad and if they are going to join a video chat over jitzy with five different with ten video streams their internet connection is gonna crash so maybe don't do that for important decisions especially synchronous communication always exclude people from a different from the other side of the world and that's still a big problem so if you want to do try to keep most of the discussion asynchronous so people can follow up when they want and when it comes to communication try to avoid ambiguities so there's many people who are interested in communication including myself who try to be funny and if you say so for those of you who are fortunate enough to enjoy a english education and maybe watch a few english shows you'll know the phrase yeah right if I pronounce it like that it's an affirmation if I say yeah right I'm being sarcastic and if your english is maybe not so good because you didn't get the opportunity to learn it at school because maybe you had to work instead of going to school then I already lost you if I try to put that in writing well all hope is lost so don't do stuff like that try really to be as unambiguous as possible it can be hard and also really so try to keep your communication simple and usually what's always a good idea to just assume good intentions most people aren't actually bad there's always you get your rotten apple but frequently people don't have bad intentions if you assume that's misunderstood them usually stuff gets resolved so try to be kind to each other that usually gets you very far but how do you make really a community welcoming and I'm gonna suggest something that people might not like but codes of conduct are actually not evil it doesn't mean that you are going to enforce rules for everything and say you have to communicate in this form and if you deviate we're gonna throw you out a code of conduct really can mean be kind to each other assume good intentions but it also means if you decide on something like that which you should you have to enforce it and you have to live by it if you just slap a code of conduct in your repository and don't do a thing about it it's not worth the paper but you get it it's really not worth having it at all because it's not gonna do a thing so if you want to put down some rules how you want people to communicate in your community how they should behave or how you want them to behave and live by that and enforce them and to have a nice community you want to provide a place where they can meet and talk so that can be a chat room can also have video chats but then again time zones unfortunately make this complicated and and also what I would recommend for all things to document processes documentation is really king unfortunately no one likes to write documentation including myself but I mean sometimes I do because documentation really helps especially when it comes to community processes when it comes to code review processes because if you let's say you get a pull request for something and suddenly disagree especially bad if to maintain a suddenly disagree who gets to decide if you have a rule written down you can point to the rule if it's just via some well usually we do it like that people will start to argue so if you can avoid somehow often very stupid things like code formatting that's something that programmers often like to argue about just use a code formatter it decides for you if you can document rules if you can enforce them preferably automatically that's always a net win but please don't try to solve social problems with technology that doesn't work it can technology can help but technology will not solve people problems you have to solve people problems with people as a maintainer you should always as a community member try to be present and try to be friendly to newcomers if you if you tell a newcomer to RTFM you're not going to see them again unless they really really really really want to use a project nowadays there's so many projects they're going to use something else and help newcomers to do what they came to do so as a maintainer you might get you might feel like someone comes in and they could solve a problem yeah but I mean I can do that in like a tenth of the time don't if you'll help them it will take you twice as long but they might stick around and in the long run that will be a win they might stick, they might not stick around but you'll never know if you never try so what I'd also like to cover is a little bit why do people actually contribute to open source because if you understand why people contribute specifically to your project you you can make them stick around longer or also if you're yourself looking for contribution and maybe need some need some reason you can find a few some people just contribute because they believe open source is the right thing and closed source is the highway so let's take my way some do it just for altruism people also just contribute for fun that I mean yes coding actually is fun if you don't spend all day in JIRA some just do it for for kinship so you like the community and you want to contribute to the community and do it for them or just for your reputation because I'm the one who solved all the nasty bugs reciprocity so you feel the duty to just give back maybe you use this project for your day job all the time so you feel like it should be you should also give back to this project it's also a great learning experience so that's most certainly a good way or the good old scratch your own itch so if you've found a cool project that doesn't do exactly the one thing you need it to do with open source most often you can tweak it you can use it as a career starter I mean I'm a software developer at Susan I don't know exactly the reasons why I got hired but pretty certain open source contributions didn't hurt and nowadays many people including myself are fortunate enough to get paid for doing open source contributions so that's also motivation now please don't get scared this terribly looking graph which you can kind of see I stole that from a paper that's also going to be linked in the presentation so if you want to keep your community you have to find you have to know why are they contributing and you also have to keep in mind that this can change over time so this graph shows you on the this thing has I think okay this side of the graph shows you the initial motivation so this has been a questionnaire for why people contribute to open source and this is the initial state when people started contributing and how it evolved over time so I think the questions were essentially why did you start contributing and how is it now and you can see a few things so for instance the scratch your own itch decreased by a lot but many and also learning decreased a little bit but people kind of stuck around for so fun increase reciprocity increase altrism and at least in my opinion the takeaway from this is that many people stick around either because it's fun or because they like the community so if you want people to stick around make your project a fun place to be and a nice place to be keeping people around because they'll never be able to scratch their itch I don't think that's going to work but you can try but I don't think that's going to be that's a viable way but again all every project is different and finding out why people contribute well you can try asking maybe they'll tell you but I wish I had a magic recipe for that but unfortunately I don't a nasty thing unfortunately you have conflicts so in your community you will inadvertently have conflicts unless you are only one person but once you have more than one person there's going to be a fight at some point with fewer people it might take longer with more people you'll get them unfortunately and I would really suggest that you try to resolve conflicts given your rules that you've put down because otherwise conflicts kind of linger on and fizzle out people will build up resentment and either they'll start to avoid each other and you'll get silos in your community which is always not fun because then they'll start doing their own things and also if you get conflicts more often with one person then the famous phrase one bad apple can spoil the barrel unfortunately it's very frequently used nowadays to say yeah you shouldn't judge the whole thing by just one bad apple but the one bad apple can really spoil everything so if you have a bad actor in a community you shouldn't be you should eventually think about removing them because they can poison the whole thing so with that I'd like to switch more into the path of a maintainer so if you find yourself to become an open source maintainer one of the most valuable skills is I think that you should learning to let go of things and to share responsibilities if you can't do that you're gonna have a bad time because if you hoard all the issues for yourself you can do that maybe for some time but eventually just a psychological burden of having all of this on your mind and I have to take care of that it's gonna burn you out so try to share your responsibilities try to share your tasks because actually what studies have found is that if you give people the rights to contribute to your project in a more meaningful way like they are allowed to accept poor requests they are allowed to merge them their contribution quality will go up so if you want to have a better project share your responsibility with that but unfortunately as a maintainer you also have to do the boring parts like take care of infrastructure write documentation you'll be doing that a lot so documentation is unfortunately never enough that's not an excuse to not do it because no documentation is even worse unfortunately people will still not read documentation but again documentation is still king so you'll also be covering the onboarding process and mentoring issue triage, merge requests maybe find cash because infra doesn't pay for itself you'll have to if you have a forum you maybe have to do moderation of the forum you'll have to debug why your server suddenly stopped working why your CI stopped working and you'll also have to start looking into licensing do all the fun managing stuff but maybe more fun things like making your project more more popular because your open source project unless you are the lucky person who found exactly the one thing that everyone needs like I guess Docker or Curl or SQLite everywhere and are something that people really need getting this one lucky project you'll have to do very little marketing yourself but if you are not that lucky person you would have to do marketing and as a computer scientist maybe or as a programmer you think talking in front of people but otherwise if no one knows about your project you're gonna use it so if you want to make a project popular talk about it write tutorials and what also works if you're trying to solve a certain problem find projects in need and send patches maybe they'll accept it you might have to be you might have to be persistent but maybe they'll start using it and over time popularity will grow and as I said did I mention documentation write it and making a project popular has also another advantage so this is Mike McQuade's contributor funnel slightly adapted of the sales funnel but the idea is essentially if you want to have more maintainers the one most common path to becoming a maintainer you start out as a user of some project then eventually you get sucked into becoming a contributor and then you get sucked further along the funnel and eventually maybe become a maintainer but the ratio between maintainers and users can be I don't have numbers but I guess it's in a best case scenario it's maybe gonna be 1000 to 1 but I guess it's more like 10,000 to 1 or even worse really depends on the project so if you want more maintainers and you have 5 users that's not you're not gonna recruit more maintainers from that so make your project more popular how do you do that so this is from a study from Mozilla that they it's I think from 2007 so it's not super recent but they reviewed how how you get people on board of the project and what the influences of certain factors are so the essentially the X axis shows the impact of a certain of a certain property on onboarding and the Y axis that's just a certain factors and what you can see is that what really has the biggest positive impact is the perceived future impact and the recent volunteering experience so really if you want to get so if you want to get people on board the vision matters what actually doesn't matter is the past impact at all so if you want to onboard people better you have to give them a vision and what they did how much impact they had in the past isn't really that important what matters to them is that they think they can impact it I mean if you just give them the impression that they can have some impact they'll eventually find out but if you have a if your project has a vision and has a path to improve it you will be able to get more people so give them a vision and also what this study found out that if you have a great onboarding experience it will motivate people to also onboard others and another thing if you want to keep contributors especially for code contribution quick responses are very very important so that's also from the same Mozilla study they did a review of how long it takes someone to respond to a pull request and they found out okay so if the maintainer responds within 24 hours to a pull request there's quite the likelihood that the contributor will stick around or that they will that they will work further on this if it takes you longer than a week the chances are zero and but it doesn't necessarily mean that you have that you take the time immediately to review the pull request it can also just mean hey sorry it's my weekend I'll take care of it on Monday or I'm traveling sorry my internet connection is like super horrible next week that's enough but just answer them and I know it sucks because it means you might have to check your work emails on the weekend unfortunately but really if you want to keep especially newcomers around you have to be quick about this and a big thing for being a maintainer or also an open source contributor really take care of yourself and don't burn yourself out over this so stay true to your motivation and why you started contributing and if it stops being fun stop I mean even if you get paid for it and the project turns into a toxic dumpster fire talk to your manager and tell them this is horrible because you must stay your top priority as a maintainer as a contributor if you're just going to if it's just going to stress you out and the thought of opening your issue tracker gives you cold sweat it's not going to work in the long run you might be able to force yourself to do this for just a while but it's not going to work in the long run and another thing that I'd like to quickly cover is feedback and as we all know maybe feedback in open source is challenging because people often come only when things don't work but then again all feedback is still a gift because you get feedback from people from vastly different backgrounds that might have read your documentation and misunderstood it because you thought you said A and they read B so still take it thank everyone for it and really in most cases feedback is not an attack on you as a person it's just something that people tell you there might be people who just are nasty assholes and they like to tell you that you suck and your project sucks and more things that I don't want to have on the recording but really don't defend yourself try to absorb it try to adapt to it and if it's appropriate discuss it but don't take it as a personal attack that you really have to defend yourself from but as I said unfortunately very very frequently but I think things are changing maybe a little bit you mostly get negative feedback on none at all so it's often very hard to get people to actually tell you what they want what they are missing to test beta releases and similar things people come to you when their stuff is broken unfortunately and that can be very frustrating can be very crushing because you don't see the 10,000 happy users you see the 10 who are unhappy and come to you and dump in your issue tracker but then again you you don't have to address everything that you receive because there's also people there's stuff that you can't react to and really not getting bothered by this is something that you just have to train so I once had the opportunity to talk to Daniel Stanberg the curl maintainer and asked him about this how do you do this and his answer was unfortunately a little bit he just told me yeah well I just don't get bothered by it as someone who is not not a great open source maintainer and struggles with things like that okay damn it so but as many things in life you can train them and given that I only have two minutes left I'm gonna do my favorite thing that's one to skip a few yeah if you provide feedback I think you never hurt anyone so thanking someone when you write a bug report it never hurts anyone and people will be far more happier I hope this didn't discourage you so if you didn't start your open source journey you can start now or please start now but if you're building something maybe wait until it's kinda ready it doesn't have to be perfect but marketing still tells you the first impression counts so the first impression should be really good this all sounds very very terrible it's actually not it's still always a lot of fun you can learn a lot but only stay in project as long as it is fun and yeah well I told you this no it's I didn't tell you everything that you didn't learn at university because we all still learn but I hope I gave you some starting starting point some food for thoughts and if you need more there's the great collection called Uncurled from Daniel Stanberg this is the paper I mentioned for motivations for contributing that's a link to the study from Mozilla and the open source contributor funnel by Mike McQuade and there's my slides if you want to find them or you can just grab the QR code at your hand if you have any questions I'd be more than happy to answer them how did you start one of your entry points so I started I I'm not sure if I started first contributing to Fedora or I started so really code contributions were to a C++ image parser which had some where I just found out okay it got someone found out that if you run an ancient C++ code base and you use AFL to fuzz it to hell you'll find about 100 bugs in an hour and I started fixing them and eventually did all the mistakes like hoarding bugs and trying to fix every problem myself and eventually burned out so that was a great example to not do things but that was my start I was already I mean at that point I thought I was fairly fairly experienced but it was I already had my master's degree so I think for like a month or so but then again I studied astrophysics so I learned coding on the side to write simulations okay then thank you for your attention and enjoy the nice weather outside thanks for having me okay can you hear me okay okay okay thank you all for being here so uh no this is not working anymore should I turn it on some way yeah yeah not anymore is it plugged in is it plugged in where should it be plugged in the receiver is plugged in should we turn it on thank you well it was working but it's out of batteries okay thank you thank you so much okay no there is something with my laptop okay doesn't mind doesn't mind thank you so oh yeah so oh probably this is the cause I can try again yes no sorry sorry okay my name is Maya I can say that I'm passionate about home automation probably because I worked in home automation sometime for a while I also have a sort of smart home and most of all I believe that we can improve home automation and what you will see in the following slide is almost this what are the problems I see in the home automation systems today how I'm trying to solve the problems I see in my way and in the case you want how you could use this project that I'm trying to present you and this entire entire talk is about a smart just on off nothing else that on off lie I mean as which and this is my first question why do I buy as which to put in my kitchen so one reason is when I cook my hands are dirty outside it's dark and I don't want to switch on the button my system should be smart enough to turn on the light automatically but sometimes even though outside is dark I need for some reason I don't want my light to stay turned on and I want to be able to say to my system that it should leave the light turned off even though outside is dark and in the very same way when it's bright outside I always forget to turn off my light because I I didn't I don't realize that the light turns on and I want my system to do it automatically but again sometimes maybe I'm working in the darkest corner of my kitchen and I want to tell my system okay now let the light turn it on even though it's bright outside and I want to be able to force my light to stay on and another way to say what I'm saying is this what I want is a state machine it's a quite simple state machine it has four states and in this case we are managing six events and I can explain a little maybe what's the the for example what is this first event we are managing I mean my system thinks that it's a good moment for my light to be off it receives a motion event and it could be that it changes my light to off or on it depends if it is dark outside or not and maybe we can spend also one more minute on the forced events we can go from into a forced event starting yeah we are if my light is for the system is off then I can force on and if my light is on then I can force my system to to an off state to a forced off state and one more thing could be how can we exit from a forced state we can use again the same push button so we are forcing it off if we are in a forced on sometimes I use also the events to exit a forced state it really depends on the state machine you want for your device and that said my next question is how complex it is to find a reuse for me such an obvious automation and I try to answer the question using which I think the most of you know but for the one that don't know this project is nowadays I think the biggest open source project we have and yes so I'm looking something for home assistant and this is the closest solution I was able to find this is not written by me I found it googling for a solution for my problem so we now go through this code it's not so long but let me tell you something about this first thing is here we are reacting to a trigger and so we are managing an event but we should guess which event we are managing and probably this is a motion event and we can guess this by reading the name devices which made the trigger and when we have guessed that this is a motion event the next thing is understand which will be the state of our light and the state for our light will be a non-state because we are calling a service that says turn on my light turn on my kitchen light my kitchen lights and we are also saying that we wait for another kind of event and again is an event regarding the motion this time is a non-motion event and in this case the final states for my lights will be a non-state because we are we are calling a service which is light to non so in this script we are dealing with two events and two states for the lights there is something more these guys also as designed a Forcedon state some sort of Forcedon state and he used for do this an input Boolean an input Boolean is a graphical is an entity in Home Assistant that you can use and it name it this entity kitchen light override and when this kitchen light override is selected then what we get is yeah I want to okay we tour when the input Boolean is selected then we turn off the automation we have seen before so we don't care anymore about the motion and we said and also we say to the system okay turn on my kitchen lights so we disable somehow all the logics behind the motions and yeah this is almost the same but it's the default case so when the input Boolean is not selected what are the problems I see here I yeah I can summarize them here I think that this automation is complex to be reused it mixes together the states the events and the triggers the triggers I have already said that we need to guess which are the events we are reacting to we need to somehow guess which are the states for our final light and this is more visible when you have more scripts that then take care of the same devices and also another thing is in my mind when I think to a forced on state for a forced off state I don't think to use another entity in a user interface or maybe another push button in your room I mean I have a push button that can control my light to the system now I'm forcing you to behave in a different way with just that push button and one more thing here is not listed all we have seen was dealing with just three events out of the six I need this is another problem we have this light automated and to the end user the automated light looks like this I mean it's like any other non-automated light I don't really think this is much useful how can I tell if someone has forced my light or if it is just turned on because the system knows that it should be turned on and if I want to force it you probably can say me that I can put here near this widget, the other widget, the input Boolean widget but if I am the one that has written the script probably I can't understand it otherwise maybe that's not the case and it's not just a matter of widget it's I think much more a matter of models and I try to explain you what I mean with this light here we can see the history of our light here sorry it's in Italian the first it means turned on, the second row turned off, the third row turned on and the last one turned off again and I wonder if someone finds this useful really useful I mean I never look at this kind of history because okay I can say that my light has been turned on for a while maybe I can say it's more than I need but behind my light there is much more I think I want to be able to see all the other events that can make change this light for me this model is just on off model it's not helping you and the others in your home understand what is going on and I think this is the cause this is taken from the Home Assistant website and I think the really interesting sentence is the first one I mean this one Home Automation itself has never been a goal of Home Assistant and I think that the point is this Home Assistant is all the other Home Automation system I know are thought to be to let you control your devices not really to automate them and if you remember in this slide we have seen before there were a big for there was a big focus on the voice control because Home Assistant is putting a lot of effort in making you control your devices in just another way using your voice and that's their goal so you can say to me but we have a rule engine in Home Assistant and we can use it and that's true but what I think is that this rule engine are designed to let everyone, almost everyone create simple automation in a simple way and to answer my own question if I think there is enough automation in Home Automation I think the answer is no but the reason is why we haven't the right tools for doing proper automation I mean complex automation so in this second part I would like to show you what I think what kind of solution I have almost working at my own and yes let me show you so here are three switches no more than switches but you can see that the second one is not in an on or off state it has another state the Forced State and this is something that knows just the system but the device itself but for me that's enough and near the state there is the events it receives and that makes the automation change and you can also spot that are different events so this means these are all different automation for the very same kind of device and this is again a history for the very same devices before in the same time but this time we can see something more we can see that the second time the light was not just on it was Forced On and also we can see that for a while no one was there and since it was Forced On the light stayed on since someone Forced It and few seconds later someone work near the light and it turned on but this time was the system to turn it on I think that here we have some more information and another thing I have I can interact with the automation I create and this is not really something that I use everyday I mean this is just useful if you want to debug your connection I mean when you connect your automation with your devices or maybe when the system for some kind of reason goes out of sync maybe it was just shut it off for a while so the system okay this is not something I need everyday but this instead is something I really use and this is something that let you change your automation accordingly with your needs what I'm saying here to the system is stop managing the brightness even behave like if outside is always bright and in this way this automation will end up not turning on my light again automatically because it's like there is always bright outside maybe this is not the best example I probably use this feature more with other models like the blinds model or other kind of devices but I think that be able to adjust the automation to your needs because your needs changes it's something really useful and to summarize it which is the difference between this project and the other project I know the difference is that I write different abstract state machines for every automation I want and this state machine became become the model of different on-off lights which are all the same device in the other automation system all the lights are all the same lights always the same model now we can go through an example of how to use this project so the first thing you need is to choose your automation choose your model so for example I have put here two models the kitchen model we have already discussed and another simple model like state machine I could use for an outdoor wall light and after you have chosen your model you can put it down so you give you give them a name and so like this and then what is missing is how to connect these abstract state machines to the real devices and here I'm doing this so my wall light my outdoor wall light is a KNX device so I'm saying here that this command is able to send an on command when the state for my abstract state machine is on or for set on and is also able to send an off command to this address which is a KNX address so no internet address just something different and yes is able to send also an off command when the state is for set off or off in the same way we need to to send to the abstract state machine the events we need to say which are the which are the messages on the bus that trigger some event so for example messages to these multicast addresses can be mapped to the event on if the command inside the message is on otherwise they can be mapped to force it off if the command inside the message is off and in the same way we can connect the kitchen light in this case I have not which kind of device I have behind my kitchen light because I'm connecting to it using Home Assistant as a gateway so I just know which is its name for Home Assistant and yeah in this case the commands can manage just the on case or the turn off so I need both of them to be able to manage the on, force it on often force it off state and in the same way we have done before we need to map also the messages going through Home Assistant that triggers force it on event and the force it off event and after I have done this I can put together my two lights this will be used later I need for the kitchen light to manage also the motion, no motion events and here I am sending this kind of events to my state machine so oh sorry so yeah in this case again my motion sensor is a KNX device sensor so I'm listening to a KNX address and I'm mapping this message to an event that has this name maybe can be improved but it's like motion event and in the same way when we have no motion anymore and this is quite simple I think this is more complex how can we deal with the brightness I mean it is simple if we want to if we want to just yeah I mean the simple solution brings with it that if a cloud across your sky then the light will turn on otherwise it will be turned off and I don't want such cases so I need an integration of the data for this I need a scheduler and this is why this example is a little bit more complex so here I'm collecting the data that are coming from a sensor again a KNX sensor and that data of light and I'm using these two triggers that says okay this is yeah sorry this is greater than this value if the collected data is greater than that value then send to the state machine a brightness event and this is saying if the collected data is lesser than this then send to the state machine the dark event and yeah and we need to scheduler it to collect the data every 60 seconds into the scheduler and we do this like in this example so we are scheduling the triggers which will send their events to our state machine through the performance sorry so these are looks I think yeah you can these triggers don't really know the value you put in so you can put everything but my sensor is measuring looks so these are looks and this is done we have completely automated both the lights and all the events for all the lights so for one light six events for the other light four events and probably you are wondering what about building your own model you need to be a developer because models are written in python and yeah state machine written in python but at least I think that they can be reusable so I try to make them understandable using BDD testing them with BDD and using BDD you can then read their behavior and yes at least these and yeah which is the difference between so another from another point of view which is the difference between home assistant and this project in home assistant you have your physical device already modeled and you write an automation around it in this project you write the automation and then you tell to the system how to interact with your automation how the physical devices can interact with your automation and I know that this can seem boring but I really like this feature because it really gives you a lot of freedom I try to do just an example I have these blinds they are not outdoor are inside my room but I have no sensor inside my room for detecting my window are open or I give up of using any kind of automation because it's too dangerous to close automatically the blinds when the window is open or I can have a complete automation and just take the automation that it can only turn up the blinds and this is what I'm doing I never connected the down command for my blinds in my automation because it's too dangerous but the automation works perfectly with all the other states when it comes to to move up the blinds and here are the links related with some example for the project and what's next if you won't try it out let me know what do you think and if you want you can improve it and yes now any question about the state someone is in the room or the sun is up and they're having triggers sort of the information that can be into that state do you think about that kind of in your model I'm not sure I got you but okay yeah so if you just have an it's a non-binary thing I'm old so it's fuzzy logic instead of neural network whatever but it's basically there's a 100% chance of presence and it goes down and it stays over time and I can't have a threshold where it's like a big problem and it was there because my wife did not like the lights go off on her if I understand your problem I don't like to turn off my light in the kitchen state machine if yeah yeah sorry yeah it's okay yeah so I have a window sensor yeah how easy would it be if you go and buy a $10 window sensor to add that to your model you have an existing model and you add a window sensor how easy is that oh sorry I have to change it yeah you've created your blind thing and now you have to tell it how do you program it now with the team how do you program okay hello and welcome to this talk it's called officer's automation struggle between comfort, openness and usability I will have first I will have a few questions does any of you have been in my talk last day of going first nobody amazing do you, are you familiar with Home Assistant amazing have you ever heard about ESP IO have you ever heard about ESP Home amazing amazing so let's start thank you very much for coming so who am I, my name is Tomasz I'm the bold bearded but barbarian from the east, I came from Slovakia and I moved to Czech Republic about 15 years ago I considered myself a software engineer in Griezmanki, what does it mean I worked as a software developer for 10 years now I do operations, system administrations and software development on the side and my motto somebody gave me a sticker on this year's FOSDEM and the sticker said I can write my own zero days, thank you very much so this became my motto I live by it, I can write my own zero days and I did it on numerous occasions so what's the motivation doing this talk and what's the motivation even like home automation and smart homes the open source way so the biggest is privacy, we all know as I talked about the struggle we all would like to have those devices that you just connect to the home and they work and they are safe they do not steal your data they are not spying at you and the software engineers did a good job I'm not sure how many of you are software engineers I am and I don't trust software engineers because I make mistakes everybody makes mistakes so I pinpoint one thing this is a picture coming from a relatively recent paper which is from German and Netherlands universities and the cooperation those two universities Max Planck's institute and some other from Holland, I'm sorry I don't remember the name so what they did is they tried by bunch of smart connected devices and connected into the network with IPv6 you know that amazing new technology it was invented in year 1998 and nowadays still only 30% of requests to Google are over IPv6 this is a great example they took bunch of smart TVs created in the years 2019 to 2022 most of those devices have implemented the standard from the year 1998 meaning they were able they created something which is called Extended Unique Identifier which means that in the first implementation of IPv6 your MAC address was part of that address so you buy your TV from a renowned company and you connect to the internet and then you realize there is your MAC address there is your other space what happens you can be tracked you can be tracked amazing new technology nobody did anything wrong just forgot to read the documentation which was released in year 2000 it's a time point so you mean here yes because the laptop uses privacy extensions for IPv6 so it has randomized the part of the MAC address but you still have on your network that one device which is identifiable hey it's the same network it's the same guy this TV, his computer and here goes the advertisement so this is just one of those examples it's really nice one because it's a relatively new one the others you may have read the news Amazon got fined 30 million dollars for privacy violations and there is much more every year and we will see much more every year so that's why I started this project about 5 years ago when I bought my house and decided to make it connected to everything so this is how I started I started with simple home assistant installation with the PostgreSQL as a database and ESP Home as a building block for all those sensors and cameras it's stuff that I have this is where I have moved this is 3 years later so it's about 30 environmental sensors about 20% bunch of cameras and I have added it I have removed some stuff from the stack I no longer use PostgreSQL and I have added a new framework which is called TASMOTA I'm not sure how familiar are you with it I will get back to why a little bit later and this is basically where I got regarding the connected devices that I have at my home all of them except 6 are handmade by me others I bought and flashed with open source software so how did I get here so from 1 Raspberry Pi which I experimented with to cosplaying as a sysadmin so now I'm running to firewalls to storage nodes, to virtualization nodes too everything on the double that my house is always connected and I can rely on me flipping the switch and the pump going on or the most important, more important thing when I flip the switch it goes off so I moved slowly but surely from Raspberry Pi this is the Raspberry Pi 4 but I started with 2 which was 32 bit ARM I'm not sure how familiar are you but 32 bit ARM was a mess I tried a number of boards the performance was not there it's fine if you are experimenting with it when you have small networks with dozens of devices it works perfectly, nothing to fear of but the moment I started to grow I realized that ok what will I do? let's try a new hardware so I tried one of the first 64 bit ARM boards which is NVIDIA Jetson TX1 which was widely available and under Home Assistant and that, that suffice for some time but then you hit the bottleneck as with the most ARM board at that time which was storage, it only had one setup board which is slow so that is 6 GB, it's very slow storage nowadays so I moved to standard hardware PCs, X86 64 machines nothing fancy just the consumer grade hardware put it together, deployed stuff and over the time my wife started complaining because you can see there are 3 nodes there was another 3 nodes just lying on the ground around the house so I decided to optimize and start playing as a seasoned man so I bought my first rack built everything in it and it didn't work so after a bunch of debugging and redeployment understanding all the underlying technologies I choose to use Trunas as my storage server which is a really nice open source project the scale offering from them is based on Linux so no BSD needed it does replications, it does all the magic for you and you don't have to do a thing Podman for running some of the infrastructure related things like databases I do Influx DB running Influx running some pipeline for image recognition that's where you can see a bunch of graphics cards there to be honest I have to admit the picture is from the times when I was mining but I still have the hardware so why not to run something useful on it so I started to play with different things so let's get to what I started using compared to my previous solutions in the first talk at DEF CON like three years ago I presented different set of sensors that I was using but over the time somebody pointed out some other sensors like the image one which is CO2 sensor which is basically a replacement unit for some AC something but you can buy it relatively cheaply it's a relatively good CO2 sensor then there are couple of Bosch sensors which is environmental sensor and sensor for illumination so I can say I can tell if there is enough light in my rooms and if I need to turn the lights on and the presence detector which is basically a microwave radar it uses reflection as a means of identifying movement in its surroundings I am really surprised how precise this sensor can be if you have the right board behind it and the right piece of software you can make it tens of millimeters precise which is nice and there will be it regarding sensors the other thing that you need if I needed I wanted to work with our displays sometimes you just need some information you need quickly see for example the pump is half of its cycle at home I don't always have a notebook with me so having nice randomly placed displays will show you some information can be really useful I will just pinpoint a couple of them which are really nicely supported in the ESP home platform and those are the two small OLED displays they are amazing colorful really nice and really easy to work with then there is a two of TFT displays which are LCDs which are LCDs one of them you can buy as a separate module or maybe both of them but the seven segment one is used in some devices such as this one which is power metering device and they are nice they are colorful but they are small and they don't have really high DPI this is 240 on 180 I think or something like that so really small number of pixels and then I saw on the internet there is this nice IPS display that you can buy 7 inches cost about 35 euros and it can do high DPI so I bought it and then I realized you need windows to write the UI and I was surprised here my experiments with the next gen displays end up because I don't run windows I don't run all source applications I have no way how to put the UI on there but it's running ARM M3 Cortex so there is something over there I was able to get a serial console on it but I wasn't able to flash it my embedded knowledge is really limited even when I'm standing here talking to you I do not know that much about embedded systems but I know something so be afraid of MCUs this I choose this platform as something to show you I haven't have to do a bit of soldering to build these two things don't be afraid of it you can just buy this is a platform from Chinese company that you can stack together it has standardized connectors you can just put it all together write your own code flash it on there and play with it it doesn't hurt and it's really simple the ESP home that I was mentioning is basically declarative framework which allows you to write code without writing code so you need your YAML files and they will generate the code for you and create all of those bindings that you need to the libraries that you are using all the drivers that you require so they don't bite and another thing that I have added to my smart home or connected home is a parametering so these are those products that I don't build because working with mains power and switching mains power can be really dangerous you can see nice example of the danger here this is not my picture just took from the internet but I used the same box this was error of the user he connected wrong inputs but I have seen similarly burnout box one of mines when I used this device which is the dual R3 from company called Sonoff and they guarantee you 2000 watts of resistive load so I connected 2000 watts of induction load to see what happens who would expect that it burned burned really nicely so this is really interesting bunch of products from the company called Sonoff as you can see here so what do they do this line they call do-it-yourself so there is a serial console I'm not sure if you can see it probably not there is always a serial console somewhere there all of those boards have it it's under the hood either they have just soldering pads they directly give you the serial console and as we know where is the serial console by the way so you can basically flash whatever you want there I will mention all of those devices so these two up here basically the one the one on the right is an older revision that the company already stopped selling I believe it's because of the circuitry they used it wasn't very well it wasn't very well built for the purpose that it was supposed to do they it's about five months they created an absolutely new version which is called Power Free which is the biggest box here and this is really interesting because they listen to us they listen to people who use their products and they created box which is able to reach five kilowatts of induction load which is amazing so what I did I tried and it works I connected my three and a half kilowatt induction load on it and now it's switching I think it's 3500 cycle I just automatically switch it every day couple of times to see how long it will survive I will definitely update my page once it dies because I'm looking forward to see if they have learned something because one of those the Power Air 2 used a really cheap relays and after I did this test with them with just about couple of hundred watts after three 5000 cycles somewhere around there most of the relays get stuck and that's not something you want especially if you are switching some load that can be destructive or pumps and things like that you want to have reliable relays and reliable switches so this parametering device is the newest one is probably the best design also because it uses CT clamp so you can see that the measuring interface is basically outside of that circuit which is not through in all of the other solutions by them in all other solutions it's directly on the board there is some resistor which is used for measurement of the voltage and measurement of the current but that can lead to fires doing it this way doesn't matter what you will put through there if the cable does not melt you should be okay and I just mentioned free of the sensors that are used there for those of you who are interested basically one propose things to measure current differences and voltage differences go figure how and why they use those free the last one is probably the most precise one those two are probably the cheapest ones so that's about parametering so let's talk about how we connect those devices I never had any reason to do anything else the 2.4 gigahertz wifi because it was too expensive I didn't see any reason for it but couple of years ago there is this shop called Lidl here in Europe where you could get one of those boxes which is basically a base station for ZigBee with some RTL like MIPS SOC and some ZigBee SOC and so me being me bought it for I think 15 euros or something like that I opened it which you don't find there is a serial console in there so I tried I played with it a little bit poked around it but as I mentioned I'm not that good with embedded systems and there was already somebody smarter than me Paul Banks I think who already did flashed it so I looked at his work basically followed it copied it, changed the configurations a little bit and flashed it back with Alpine Linux running my software not contacting Chinese government data centers and just talking to my stuff but this this device on the SOC is not reliable the network I created using this base station was clustering all the time if I connected more than 15-20 devices so they decided to switch something different so that this USB dongle just again from the same company as the parametering devices and again they put serial console over there so you can flash it with whatever you want and it's Texas Instruments Radio based on similar chips but it's stable again the price is around 20-25 euros I have deployed three of those devices and network of 65 ZigBee clients but I was unable to make it work for longer than 20 minutes every time I try to create bigger ZigBee networks at my home they get clustered they always get clustered and I don't know I don't know what to do and I don't really use ZigBee that much I just wanted to test it so I sold most of the stuff and left just a couple of light bulbs and that's it for the other radios that I use so I'm not sure if you're familiar this is SpineWatch this is BengalJS those are smartwatches that you can buy you can flash whatever you want on them they have Bluetooth LE so they transmit a lot of information over the Bluetooth LE you can get through it I use it for presence detection so if I want to know where the people are in the house actually me and my wife where we are where do lights need to be on when they can be turned off but there is no direct integration for Home Assistant so I had to use some other means one of them was Room Assistant this was a really nice project I found out a couple of years ago it's basically really, really, really, really simplified Home Assistant you can be working on the level of rooms but it has moved to be an abandoned where what it does it basically for me it was Bluetooth to MQTT Gateway which basically just transmitted the messages from the watchies to the Home Assistant and then I could kick in the automations and do the Home Assistant stuff there there is a huge amount of implementation of Bluetooth to MQTT why most of them are just basically shell script, Python script around Bluetooth CTL we just paste the commands and work with that the difference is probably the Open MQTT Gateway which is a project that has a number of integrations and it does support a number of protocols so you can use Bluetooth, Lora, whatever you want I have more or less dumped all of those solutions and I basically use the watchies Home Assistant with its beacons and that's it another part of the setup are new cameras so probably the most prevalent that I have at home is ESP-CAM it's basically ESP32 chip with camera on it I built couple of housings for them you can see there is an AC power there is the camera I prefer when I put some mains powered things I prefer to use this kind of boxes this is electrical installation box why I prefer to use them they do not burn so even if you try to put them on fire they will not burn which is amazing but soon I realized that ESP-CAMs have huge disadvantage and that is the CCD chip it's on there it is 2, 3, 5 megapixels depends on which version you have but for my use cases which I will show you in a moment it was not enough so I played with Raspberry Pi that's better but still if you want to take a picture of something which is more than 2 or 3 meters away the basic Raspberry Pi camera is not really useful because you will get a you know there is a person who uses it nothing more the great thing about it about using Raspberry Pi is the platform you get Raspberry Pi this is the mini or how is it called which is really a nice small single core with 500 megabytes of RAM you can put Linux on there it is nice there is another thing that happened some time ago in a company which is the pinecube this is basically a Linux based camera so what they try to do is that they created a board problem for me again is the CCD it might be enough for indoor usage but for me it wasn't good enough and then we get the last thing which is just something called IP Webcam and this is the logo of the application you can find it on fdroid if you don't mind your privacy you can find it on google play as well and it's basically an application that gives you beautiful interface to a camera system you can have multiple renderers you can hook it into whatever you want you can hook it into the automations in home assistant you can hook it into different nvrs you can do whatever you want with it and you can reuse any old phone which is nice and phones have really nice cameras so here you can see the difference this is why I mentioned that ESP cameras are not enough the one with the blue car it's made by smartphone the one with the red car it's made just by the ESP cam and you can see that the picture is not so much clear maybe you have noticed there's a bunch of squares there so there's a yellow square and I'm not sure if you can read it but it says car there and then a percentage how sure it is that it is a car how sure it is that it is a car and usually it's more than 60 so it works as it goes for the software I used motion project it's a demon for Linux that allows you to use any camera input and there is another project called motion eye project which basically encapsulates the demon into the web UI for a while they were releasing motion eye OS which was basically an image that you could flash on a number of ARM based boards and it contained minimal Linux system and the UI so you could just hook it into the NVR that you already have or use it as an NVR and those boxes that you can see are created by this amazing project called dudes 2 I forget what the acronym stands for but it's a second version there was one couple of years ago it's a really nice open source project because it provides you a REST API for object identification so you just post picture there and you will get you can run locally and you post picture there I'm running in a bunch of Nvidia cards or I was running in a bunch of Nvidia cards but then you realize that mining Ethereum is one thing but when you want to process the images you don't necessarily need a kilowatt of power to consume just to process a bunch of images so I moved from experiments with graphics cards to just playing CPU work which costs less so the other important thing about having connected things is the way it notifies you so this is a bunch of connected light bulbs as I mentioned they have a bunch of the Zigbee ones when you ping me on IRC in our federal channels this is what happens at my house so I start getting notifications because I work from home similarly something similar starts happening in my office if our composites fails consequently in two days it will start really really blinking and the other thing that I built it's the wall thingy I call it the wall thingy it's basically the EVAs they found around the house and put it all together on one piece of board it's a bunch of displays one of them is currently off it's a bunch of displays you see this is the home assistant dashboard that I use this is my driveway so you can see when the check post arrives and that's it and that's basically it's about the talk so do you have any questions why do I need 15 cameras so you can't see it but there is a road here and I want to have them on the photos so that's why I basically monitor only outside of my house no cameras are pointing inward because I don't trust software engineers so I don't trust myself and only the cameras are only on outside I want to keep track but keep track about the life that's there because I live at the end of the village so I track the birds that are flying there I track the the animals that are there and you know those funny photos of your cats and dogs and stuff that you can get or the pinecube not really I always just powered it really cheap power supply something like something like I have here on the camera this is really small 700 mA and it booted so I'm not sure about the exact power consumption you have to ask my wife she is the marketing department are there any other questions are you aware of BT Home are you aware of BT Home the new standard for low energy messaging and like charging presence not really can you please repeat BT Home I will look into it thank you any other notes I'm open to anything if I was wrong I'm not correct so just tell me if that's it thank you very much do you use some in your home like when I enter turn light on so not really regarding the house itself but for example my office where the wolfing is now it's turned off because I'm not at home so yes then some small portions of it like for example especially my office is probably the most automated part of the house and then the garden because there's a lot of work there so yeah if I walked out of the office and it's after 8pm means I'm not longer at work everything shuts down and then in the morning when I wake up the home assistant realized that my watches have moved to the kitchen so I'm making a coffee and everything turns on computer boots the question is how to support Mr. Nahev if you decide to use this kind of do-it-yourself hardware like those switches I have noticed things like this it's extremely easy it's extremely easy because you just need to identify let's say person you then you need those relays to switch the things there you are and home assistant is declarative so is YAML so you will declare in the YAML file how it should act and it's actually to automation and Ansible and it will do the things okay thank you very much for your attention something isn't right good okay ladies and gentlemen I hope you can hear me well welcome I'd like to start with a simple question who of you wrote some code please raise your hand for those watching us online welcome if you are here you will see every single hand up and silly me yes it's DEVCON right all coders we all understand it now let me change the question slightly who of you intentionally wrote code which doesn't do what you want it to do and the word intentionally is important and I don't mean X I don't mean some exploits we have one I guess you are a teacher you wrote something yeah you wrote something for a student so it was intended so that it doesn't work I have never met a developer who tries to write crappy code but yet here we are a lot of crappy releases out there a lot of customer bugs what's going on where is the disconnect should we blame the testers ladies and gentlemen welcome my name is Michael Shadda and this is my take on quality engineering mindset and if we have time I would like to look into testing breakdown structure to see some kind of questions and how to apply the QE mindset itself we will talk about what QE mindset is not what it is and why it's important for the company to adopt so let's start with what QE mindset is not and I heard this more times than I would like to it's rejecting responsibility the I told you so mindset you are a tester you say hey this isn't right something is wrong there but hey it's not a priority to fix then you go to production something goes wrong and you say eh I told you so this is not what we want we want collaboration we don't want compromise we want everyone to understand that quality is responsibility of everyone and if you are not happy if you see some risks which are there don't stay silent narrow focus and that is more true some historical testing approaches where QE mindset is not about just writing tests going through automation it's about more it's about the whole development life cycle checklist mentality you cannot blindly take standards and apply them to your situation every team is different every project, product service is different it's sticking some boxes that might not be the priority which you currently need you don't want to become a roadblock you don't want the team to see you as someone who is holding us back someone who is slowing the development down I did a short survey with my friends and colleagues about what they think the QE mindset is and all of these you see on the screen are part of the QE mindset but I would like to touch some of these anyways and share some of the risks and limitations so it's a mindset to deliver quality above else imagine a team writing an amazing product something where quality is above else they do everything properly they have the best processes is the most robust service in the universe and then they go to market 15 years after the competition desire for things to be always better than they are while that's true continuous improvement is something we want sometimes good enough is good enough passion for things to be perfect for the customer and I would like to use a quote here don't let the perfect be the enemy of the good and often we can have thousands of customers and the perfect for one customer might not be the same what is perfect for another customer also we might have a different vision of our product than what customers have attention to detail and critical thinking this is a good one because we can apply it to the whole development life cycle and yes it's a strong part of quality engineering mindset but also sometimes you don't need to go as deep sometimes you need to understand the big picture don't have narrow focus the ability to understand and mitigate can go wrong for a customer we are back to our customers who sometimes don't know what they want and yes we want to predict what might go wrong but quality engineering mindset is not just about our product it's not just about our service it's about our processes it's about our automation it's about our documentation it's more so how do we define quality users getting the intended value okay but how can we verify that can we test our way to quality can we reach quality and I would say no I think it's similar to security where you can test for known issues known exploits you can analyze where we are to what we know you can never say we reached security you cannot breach us and I see quality similarly you cannot really reach quality I'm talking about quality I think it's important to touch types of quality anomalies and to see that it really is a big picture we are not limited to just bucks we have functional problems performance, security, usability and many many others and in order to understand quality as a whole it's crucial we focus on monitoring you want to monitor not only your product but you want to monitor your processes you want to find where the bottlenecks are and how you can improve quality by focusing where the constraints are otherwise your innovation will not be visible at all with this slide I don't want to go into details here but you can see that software quality field is really it has its own history it's almost 80 years old and we started with code inspections with first formulation beginnings of some guidelines testing maturity models benchmarks and we had this agile manifesto revolution with Crown and Kanban and last 15 years it's DevOps machine learning AI and question for everyone where is your team stuck in history are you still doing manual tests are you doing checklists or do you already have DevOps in place do you leverage machine learning and other types of automation and AI you have seen that the evolution is there it's very visible and I feel like it's important to mention evolution from QA from quality assurance to quality engineering and there are three main differences in mindset, in role in scope for quality assurance the mindset is really narrow you focus on vulnerabilities on verification on writing automation the role it's usually done by a tester or worst case by PMs who are trying whether it works and the scope is very limited whereas quality engineering is a mindset it's something which should be adopted by everyone in the company so the scope is the whole development lifecycle I would like to diverge a bit and talk about the primary objective of IT department and maybe go even one level higher what is the primary objective of business while in most cases to air money how do we air money we deliver value to customers and in IT companies usually we try to deliver some products or services and we would like to maximize our gains and you can maximize gains by either limiting the costs or increasing the value increasing the amount which you can deliver and where limiting the costs has limit at zero delivering the value that goes only up well not only up but you want it to go up there is no limit so really the focus of IT department should be to make sure that our developers are as efficient as possible so that the road not roadblocks so that the constraints the bottlenecks are in development in our releases not in our automation not in our testing and how can we achieve that by implementing ongoing improvements trying to make things automated better faster by making sure that quality is really shared between all the roles and by focusing on fast loops fast feedback to prevent as soon as possible and here we get to the definition I came up with and let me read it, it's a bit long so quality engineering mindset is a proactive and holistic approach to software quality that permeates throughout an organization it encompasses a set of attitudes, beliefs and behaviors that prioritize and promote quality at every stage of the software development life cycle did you notice something isn't it a bit vague isn't it a blank statement when you share this definition with a team they say okay and what like why should we do anything it's only common sense and I thought I thought about it for a long time I realized that it needs to be vague because quality is not a solved problem you cannot reach quality you can just look for regressions verify against the knowns and check out some other anomalies so why is it such a big deal why we can see in the history evolution of quality well it's important for business everyone understands that you need to deliver good quality to our customers otherwise you will not be successful and I don't want to go deep into each of these fields we have a lot, customer satisfaction product quality, efficiency, productivity collaboration, communication etc etc it's a lot so how can a tester ensure that you have quality in all of these it's simple testers cannot so that's why we evolved from quality assurance to quality engineering mindset that's where the tester takes a role of an ambassador of quality and not someone who just writes tests testers are educating the whole team and educating them about quality throughout the whole development life cycle and for testers this slide is mostly for you but others might find it interesting as well we have some common pitfalls and here's my take on this we are under tremendous pressure features, features, features that's all people want we need to deliver features to customers we need to deliver it fast so yesterday we don't have time for quality what can we do about it and I would argue that this approach already shows that you are not embedding quality in the development process because delivering a feature should already include the quality you should bake the quality into all your processes based on your needs if not then it results in bad practices you have some anti-patterns you have hardening sprints you have tech depth sprints and the accumulation of QE backlog then the developers slip the window for testing shrinks and you know the drill you go down with a downward spiral and then you pay the whole company pays and I guess if you have been in this role you met some of those pitfalls over times missed deadlines cutting corners and yes we are awesome we can do that for one release, for two, for three but it accumulates it accumulates and at some point it will all crumble and the answer what we can do about it what we can do about these symptoms of not having quality into the development life cycle it lies in the definition lies in the definition of QE mindset the whole team needs to adopt quality and together we need to implement process of ongoing improvement we need to focus on where it matters we need to pick our battles and we need to find our constraints how to do it I apologize I need to skip this one because that would be another presentation just this one part but to shortly sum it up it's a cultural shift everyone in the organization needs to buy in on quality and together we need to build a quality vision which makes sense for your team, for your product for your service and sometimes it might not be writing automation what you should focus on testing breakdown structure it's something we need to do in order to find out what the quality vision is for the whole team we need to ask questions quality is not a solved problem and it's not about creating a checklist it's really about collaborating finding the right quality vision and yes even asking questions can be misused but if we don't do that we will never know what is it we want because it's not only about common sense yes, quality might be a common sense but common sense is different for everyone so the ability to articulate what the quality vision is is crucial some areas to ask questions about work tracking tools and workflows usually this is something you design before you start working on your product and then sometimes it's forgotten but it has its own risks you can have public service, you can have public JIRA project and you can leak information there that is part of quality it's important to think about the design how we do things is it easy, is it difficult, is it efficient does it really cover reality every team evolves and at some point our tracking and processes the tools we are using they lose touch with reality documentation and that's a good one it's a love and hate relationship when you are working on something which is well documented you love it because whatever you need you will find it there but someone needed to maintain it imagine a situation where a company is losing money every minute your service is down and it's down because the main subject matter expert was abducted by aliens and well yes, you can get second best person or the whole rest of the team and try to dig deeper, analyze what's going on, what can we do we don't know because there is no documentation and at these points you tell yourself I wish we spent 30 minutes on documenting this stuff it would be so valuable process definition and similar to workflows usually you create a process so that it's clear how you develop your service and knows what they are supposed to do what is their role in the process where they can see the backlog where is the input, where is the output but even if you design the best process there is I guarantee that in a year or two it will be obsolete evolution is fast IT is moving very fast and we need to adapt we need to focus on what gives us the most value even from process perspective and it depends on what the team needs whether it's consistency performance, speed robustness we should still keep in mind that this continuous improvement in processes will improve our developers' efficiency and this will improve the value we get from our products and this will improve our revenue testing and once again we don't have to go deep into this this is the part of quality assurance focus on what we should test how we should test it, where we should test it what makes sense for us it will be different it might be even different service by service but you still need to ask those questions what makes sense to do what does not continuous integration that's something we are all trying to achieve it's modern, it's good and if you compare it with humanity and our progress usually we did the most progress when we were able to automate something when something happens without us putting attention to it whether it's water electricity or productization pipelines how can we make sure that our CI stays on top of what we are doing without asking the right questions are we doing things manually can we automate the process can we make it easier and this one is a bit tricky because if you create difficult CI then yes you need to maintain it you need to make sure that your environments are stable you need to make sure that your testing environment is similar to what you have in production so that you actually don't have some false positives etc but it still buys you time and you can save dozens and dozens of hours by properly automating things making sure that whatever you do next time it will be better and I mentioned some other areas security dependencies definitions so that people are on the same page performance optimization code maintainability all of these at some point in your product life cycle someone needs to say this is what we want this is what we don't want someone needs to decide someone needs to ask these questions to formulate the quality vision for the whole team so that everyone is on board with that and the three main takeaways from the presentation I would like you to know that quality engineering mindset is not just about testing it's about cultural shift it's about having everyone on board and it's about baking quality in the whole development life cycle the second takeaway is there is no one size fits all solution everything is different your requirements are different what you know from the past might not apply in the future so collaborate communicate implement the continuous improvements into your sprints and your quarterly plannings and last but not least we inherit the main purpose of our business we try to make our company successful by trying to make our developers as efficient as possible thank you everyone that will be all for today if you have any questions now is the time and I know the topic is a bit philosophical technical and the questions might be hard to come by but if you want to discuss anything just let me know so the question was if we identify our gaps what can we do to make sure that once we close those gaps they don't open somewhere else and I would like to actually use something which I heard from a different presentation that was about Agile integration I believe it was Fernando who did the presentation apologies if I am wrong but the idea was that you cannot finish Agile transformation it's an ongoing process you will never reach it and the same way you can never reach quality so what you are looking for what you are trying to implement ongoing improvements make sure that quality has place in your planning and in your capacity make sure that you are continuously evolving because the quality field software quality field will evolve as well and your approaches at some point will be obsolete so you cannot all you need is process of ongoing improvement thank you for the question so the question was can design team where development and quality are in balance where this quality engineering mindset is in place I would say so but it's difficult and since you cannot reach quality and everyone has their own specialization first you need buying of everyone you need buying of the whole company you need to shift your mindset you need others to understand that you really need to talk about quality at every stage and properly prioritize so it's a lot about communication, about soft skills about building quality vision with every stakeholder which has some kind of role in the development life cycle without this communication and buying from everyone you will just not be successful so if you are quality engineer you don't have buying you either will become a roadblock or you will get crazy or what you can do and what would be my recommendation is pick one small thing focus or find the constraint for this value stream mapping is a great tool find what is it that slows down your developers and work on it improve it if it's good it will be visible if it will be visible it will be adopted by others and this way slowly but surely you will incrementally get better thank you everyone and have a great rest of the day