Hello everyone and welcome to this week's Product School webinar. Thanks for joining us today. Just in case you didn't know, Product School teaches product management, coding, data analytics, digital marketing and blockchain courses online and at our 15 campuses worldwide. On top of that, every week we offer some amazing local product management events and host online webinars, live streams and ask me anything sessions. Head over to productschool.com after this webinar to check them out. Hello and welcome. My name is Matthew Jordan and I'm a Senior Product Manager at Ubisoft and I'm here to share with you today my first product development experience, how I approach the task of building a product from scratch and some of the lessons I learned along the way. This case study webinar is for those of you starting in your first product role or found yourselves being given the task of building a product with no prior experience for the first time. The product which is the subject of this story is an internal software as a service product that manages a variety of tasks and functions for live testing of the games created by our game studios around the world prior to their release. It is not something you can visit and try out yourselves unfortunately, but as is common in large organizations, custom built internal solutions are integral to internal operations, but not so much light is shed on the development as it lacks the glamour of B to C or B to B products. I learned a great deal from this experience and it has shaped my approaches to the development of other products within my portfolio today. My goal in this webinar is to give you an overview of this experience and share the insights I gained and lessons learned from starting a new product shortly after joining a new company. I've tried as much as possible to keep it true to memory and not to add in techniques or knowledge that I know now but that I didn't at the time. I'll start the story at the beginning. Chapter one context, problems, needs and feasibility. Ubisoft is a large company with production teams based all over the world of different sizes and resources and as our games were even more and more online the need to perform live testing of them was increasing in importance. There was however no shared or centralized approach or processes on how best to manage the live tests. So my management tasked me with building something to answer the needs. It was really that straightforward and simple, no brief or guidelines, just an objective. I was and am still today fortunate to be within a supportive management structure where I was given the freedom and autonomy to explore the opportunities arising from the simple objective of finding a solution for live tests. My first step was to understand the needs of teams, what is problematic for them, ideal capabilities of a solution and formulate a solution to them. I needed to build a global view of how the studio teams and all of the stakeholders work. As without knowing their environmental constraints, problems and needs, I would not be able to formulate a viable solution proposition. At this point I was working by myself and the first step I took was to do a feasibility study which contained a key task of contacting many stakeholders around the world from a variety of direct and indirect positions relating to production of live games. I had written a short survey to conduct in person, on the phone or over email to obtain information on their experience with live tests and indirectly to garner their support for the endeavor I was undertaking. Something that would in the future pay dividends as several stakeholders I worked with would continue on to be internal users of the product. The information collection phase was relatively straightforward as there is a strong collaborative culture within Ubisoft so I was met with a lot of enthusiasm and forthcomingness with information once I explained I was here to help. I put all the responses together along with my research into potential external solutions and our capabilities to develop an internal product into a feasibility document and decided the best approach was one where we could tailor a solution from the ground up to target our needs and avoid any superfluous feature sets or constraints that could be encountered from an external solution. This was centered around an assumption that an end-use operated approach would be a best fit to their needs. To ensure the product maintained focus I devised three pillars that should guide our concepts, help triage your features and structure roadmaps. The first of these being that the product needed to be scalable meaning useful to both small studio production teams with less resources as well as to larger production teams who had higher requirements for volumes reliability and connectivity. Secondly it needed to be flexible as production studio teams needs were not universal. We set out to make the product as modular as possible with features being a la carte to enable us to provide teams with everything they need and nothing they didn't and a microservices approach that if one power were to fail the remaining operations would remain up. Lastly we needed to build a centralized solution. Our teams are widely distributed around the world so it was not possible to offer local support and we needed a variety of different systems to talk to each other to enable the needs of teams to be supported. The product functional and technical architecture would need to be adaptable and robust as we would be a central point of API requests and calls. I found this definition of pillars approach very useful as it created a filter with which to review any future developments and feature developments requests we were receiving. They needed to meet these pillars objectives otherwise it didn't fit with our core needs and wouldn't metaphorically hold up the product. So at this point in the story I know what production teams are needing and wanting I've identified an internally developed product to be our best bet as our business solution and identified three pillars to guide our planning and development. I presented my findings and recommendations to my management and was met with approval. Now I needed to get things moving. Chapter two pilot projects and communication. Taking the vision to find at this point myself and a technical project manager set off to solidify our plans to build the product I had in mind but this needed to be on paper for others to follow. It was at this point that I started the internal promotion and awareness of our project for two reasons. Firstly to update all stakeholders we were moving forwards and that we kept them informed of progress and were open to any input that they had and secondly to avoid any duplicate projects arising. As a large software company more than 15,000 employees internally competing projects can arise and I wanted to solidify the first mover advantage and consolidate efforts on our initiative. This was to ensure production studio or support teams weren't needlessly using resources to build tools or local solutions just for their tests when they could contribute to something much larger and comprehensive for all. I'm wanting collaboration over competition. To make visually accessible the scope of the product I put together a concept map effectively a clearly defined feature map consisting of branches that address key groupings or features such as player management and feedback management. There's many good applications out there for building maps to explore ideals and I built my first mind maps in Coggle and then solidified all the branches so that there were no more than two from the center to enforce the organization and categorization ideas. With this we could easily explain the scope of our product at a high marketing level and also serve as a guide for strategic direction. An important approach I wanted to take was to pilot a product directly with production teams. This involved recruiting three established large production studios to agree to work with us for their titles to be used on the product once released and be a part of the design and development process. My objective here was to ensure that we were building what we were building was as much as possible in alignment with the real needs of teams and not end up in a black box scenario where we would toil away with the initial needs in scope only to return a year later with a ready to launch first version that was no longer useful or missing too many features to serve needs that had arisen or changed in the meantime. Monthly meetings were in place to update the pilot projects and when feasible we visited their studios to demonstrate progress and functional user flows. Now that we knew where we wanted to go and who we were going with we needed to drop the plans. I did this by first writing a yearly strategy document which outlined all stakeholders visions and goals risks and resources needed for the first year and key features to be part of the MVP. From this we built our first roadmap which was in two phases. The first phase was to build an MVP based on agreed needs with our pilot teams. The second once we had delivered and demonstrated this was to adapt any additional needs and refine the MVP ahead of our first live test which was to be one of the pilot teams early live versions of a significant game. Our two key deliverables were being able to acquire and manage a database of players with acquisition coming in the form of players being able to register their interests to participate on the game's website and secondly manage the distribution of the test version of the game to players. In this case on PC to a volume of around 100,000 accounts in a very short period of time typically a few hours at most. Common practice sprint organization and development was undertaken against a backlog of these features but with a strong focus on no needs and importantly reliability what we had to deliver was not a consumer product we could roll back and pull off the shelf if it wasn't up to the task of launch. On the back of our main assumption was that with enough testing validation and preparation we would be fine with such a controlled environment. Chapter three development and sticking to the plan. Now we were ready to develop our solution with two key success criteria of being able to acquire players through website registration and being able to distribute access to players directly to their PC gaming accounts without using an intermediary solution such as a token or a key. Two developers and a tester joined the team and we completed sprints over the course of nine months making alterations after pilot project consultation as required. An important decision point was reached during the development period as we progressed and promoted what we were doing production studios outside of our pilot team were taking note and we were requesting to use our solution ahead of time. We were faced with the question of do we give in to the temptation and excitement to have our product working earlier showcasing improving that we could deliver. I took the decision not to launch with this earlier team if I was unable to be confident we'd have the reliability they would need I wasn't prepared to risk their live test nor the reputation and trust I'd built so far in the journey. I maintained a quality first approach and as I was the ambassador for the product I had to protect it from any reputational damage lest we lose support. I was also wanting to avoid adding any functional debt so early into the product by cutting corners on the MVP and implementing partially what we'd agreed to do. I was not in the mindset of close enough is good enough. We may not have accrued any technical debt as our code would have been clean and done what it was supposed to do but our user experience would not have been good required too much operational workarounds and risk populating invalid datasets that we'd have to tangle with in the future. We continued on with development and testing and we're ready for one of the agreed pilot projects first slide tests a few months later. Chapter four always expect the unexpected. We were now ready to launch with one of our pilot projects using the distribution set of functions. We passed UAT and production environment testing coordinated the operational tasks with the production team and on the time and date specified we commenced the distribution process for players we were live. All seemed well until about 30 minutes in and we realized something wasn't right. The process was getting stuck. An important lesson was learned here. Tests thoroughly and also realistically. Within the process flows we had learned thorough low testing on servers and APIs but what we hadn't done is test the functional flows at the same time and volume we were going to use for the pilot. Now there were some constraints to doing this at the time. We couldn't test by giving 100,000 testing accounts to real players but in hindsight I would have focused on a solution to this constraint which we did go in for. The root cause in the end turned out to be a misconfiguration on the database causing data corruption something not uncovered in our testing. So everything stopped and we worked frantically to address the issue with infrastructure teams all the while taking careful notes of what was happening for a later incident report in post-mortem. In parallel to this it was paramount to keep live contact with production teams to advise of the status and to allow community management and support teams to respond to players inquiries as to why they hadn't gotten their test scan. All the product testing and validation reports in the world won't cover 100% scenarios so it's important to be ready to respond. There's no set and forget mentality and as we were now the face of the product we carried the expectations of any performance. The issue was fixed and we recommenced. All in all only a few hours were lost and our relationship built with the production studio to this date meant we hadn't shaken too much of their confidence and positively added to their perception of us by how we handled the issue and resolution. The remaining functions all worked as expected and the live test was a success in the end. We had turned 18 months of information gathering planning and development into a real product that was operating and removed a host of manual and slow tasks from production teams as well as building the first steps of a platform to provide a host of future benefits and opportunities. The epilogue. It's difficult to simplify complexity. A major assumption that was challenged again and again in the first year after launch was that live production teams would be able to easily understand the product, the many variables of the company's technical and functional ecosystems and coordinate with these other stakeholders for launch and self-manage the platform for the test themselves. Understanding all the moving parts and requirements of the ecosystem outside of the production studio and how this tied into our product and its setup was too complicated to pick up and understand quickly. My 18 months of learning the ecosystem needs cross-functional team requirements and defining processes could not be transferred through meetings, tutorials and productive support. The production teams did not have the time or resources to dedicate to managing the requirements of the product. Their focus was first and foremost on the game they were producing. Fast forward to today and we've since built up our team to eight with an operational team and a series of processes and procedures for onboarding new teams, managing issues, coordinating a diverse international set of multidisciplinary teams who all contribute to a live launch. The product is the platform that now globally manages all the user flows, functions and requests for millions of plays each year and is a critical part of our live productions. We are still evolving, adapting and solving problems to support our global production studios and a flexible and modular approach from the beginning has been crucial to our success. The evolution of feature requests and prioritization is largely based on my approach of, is it for the greater good? We have many teams so developing one specific niche or nice to have just for one of a dozen production teams doesn't fit this underlying approach. Features come from internal and external drivers and must be leverageable by other studio teams, otherwise we start to get features for and branches of our product tree with only one leaf. So we'll often look and see how it can be made to have a broader utility and if it can't then we keep it on the shelf until the more widespread need for it arises. We've also decommissioned or removed aspects or functions of the product. These could be functions we planned marketed to teams or built MVPs for but never found a home or where the underlying assumption of utility was disproved in prototyping or practice. As we've held the operational aspect, the balance of feature requests and priorities have shifted from the users to us internally. As the product team has become the body of knowledge and experience on how to perform live tests, build frameworks and with this we presented at several internal summits around the world to further spread our product and assure teams that with their games and our support they can be ready for their live tests. So with the story behind me, I'd like to highlight three main takeaways my first product management experience. Firstly, envision, plan and build modular and flexible foundations to your product. As your assumptions are challenged and needs evolve you don't want to be restricted in future development and feature opportunities due to rigid frameworks and architecture. A microservices approach for central operations proved critical to remove as much as possible dependencies within the system. If one were to fail we could revert to our contingency plan only for this service and all others continue unaffected. A modular approach allows you to build what you think a team needs with them but allows you to abandon assumptions and how you think something should be done in favor of the realities and needs of your users. Secondly, be transparent and proactive with your development roadmap and be its champion. Your users may not know what they need or their needs may evolve so ensure that they can see what features you are tracking to build for them and ensure regular opportunities for them to voice a change, addition or notify of anything obsolete. Internal customers and users should be viewed just as demanding as external ones but with the benefit of being much more readily available. You can call your colleagues around the world, present at workshops and set roundtables to discuss ideas and present proposals with relative ease, market the idea and solution and be the face of the product and inspire trust and engagement. Finally, my third point would be to find stakeholders to pilot your product with. I consider this invaluable as it forces real-world requirements to be baked into the foundation. We did pre-feasibility, development and first-live usage with our pilot teams enabling immediate and direct usefulness. It also builds greater trust from other non-pilot production teams. As we weren't presenting a new product out of the box, it was being built with teams so no one was going to be the test subject on an unknown solution and risk their first-live operations. I've now finished my story and I hope this has been useful to you, whether it has given you some insight or comfort that we're often in the same boat trying to navigate uncharted waters on your own, especially daunting for your first time. I learned a great deal from this experience and hope that sharing a part of it here in this webinar has been helpful. Thank you for listening.


Okay D working group documentation subgroup meeting for June 14th of 2022. And if you do not have a link to the agenda, I can drop it in the channel. Please put your name to let us know that you were here. And take a moment to look over the agenda and. See if there's anything that's been missed and basically a lot of copy and paste from the last meeting. Just because folks have been so busy. And let's throw over to you Brian for technical documentation stuff and then I have a question for you that I added to to that item. Okay, so I've been looking at. Where we want to go with the technical documentation. Obviously the conversation at the last general group when we potentially going to add a second OS. I've been looking at what implication that has and I've also been looking at which goes to a pre meeting chat is to how easy it is to join the community. And I listened to a talk now and I'm not sure whether it was an internal company talk or an external one. I need to go find it, but they were talking about what makes a good open source community. And one of the factors of the really successful ones is the ease of boarding ease of getting into the community. If you have to struggle, then you get the diehards that really want to be there will join, but you're not going to get people with a general interest to come and start participating and becoming active member. And I think, I think we need to look at that because, as I say, we can't build easily. And so I am looking at what are the options so I've actually just put a pause on what I was going to do and I'm just trying to think. Most strategically where do we want to get to the documentation. And I think we do want to get to a point where somebody can build. And even maybe to the point where we have the scripts or the GitOps setup that they can just import with a very easy way of this is how you can get started this is how you can do a build with almost zero learning curve. So I think that's where we want to get to the challenges. How do we get there. So that's the way that would work for both for Dora and sent us streams. So, so that's where I've been looking at so I've been looking at things just like is there an easy way to do that we play strategy where we've got the internal images. There are a couple of technologies that we could use whether it's a, whether it's a hook mutating hook, or whether it is using the cryo, going and figuring the cryo mirror with the tag thing I think we have to put a machine set, config or something in there. The configuration only does the, the hashes at the mirror at the minute so until version 412. So I've been looking at things like that. Can we actually get a generic pipeline tech on pipeline going. I've also been looking at how do we get the base tools within okay D so we can use the community, get off the operator, I put a link in the chat, and if you go to the tech Tom project they have an installing an openshipped page, and it's a one line command. So it's not the operator and setting it up that way but there's a one line command on the tech Tom dot whatever it is tech Tom dot dev site, which puts tech Tom adds the menu item in and yet we don't get all of the operators only the tasks and pipelines. But could we then build something in our in our repo when we have the repo that says import this and you get a build pipeline and just plug in the name of the component you want to build or something like that. So I've been doing a lot of exploring around. I'm hoping with the idea of coming up with a proposal of saying, this is what we want as a, a sort of no hassle getting started a building your own rather than just having to go. This is how you find the repo and by digging around I'm sure you'll find the way in which you can build it because I don't think that's an easy getting started. And ideally we do want to maybe push something in and I know Mike mentioned it that maybe we can actually try and get a standardized approach across the repos because I've also been looking at what are the images. And I was shocked at how many base images how many different base images. Now I know the prow system does a replace. So they actually don't build from those. But if you look at the state of the repos, there's a huge number of base images where they just haven't been updated because they're not used for active bills. So none of the maintainers have been looking. So I think there's a set of actions like that where we can go and maybe do raise issues or do pull requests on to the red hat repose and suggest that they change the base image and come up with a standard of doing that. So maybe get some getting some of the red hatches to push that internally within the community as well. So that's what I've been looking at. So I've sort of stopped adding new content and I've really just taken a step back. The idea is to come up with a proposal that we can get everyone to agree on. This is what we want the getting started experience to be for developer not for a user but for somebody wants to contribute, maybe customize maybe do their own build. So one thing I want to ask is, how do we. How do we get people beforehand to participate in the group? How can we as the documentation subgroup. Get people interested in writing some of these docs in contributing towards writing some of the pipelines that will. You know, swap out images and build and whatnot because that's to me, there's the three of us. You know, and Michael, when he has time, right. And to me, if we have a concrete plan. And we have a concrete ask, I think people are more willing to join. And participate if it's not a. And naval gazing exercise where they just haven't got a clue what they're. Yeah. So, again, that's why I want to come up with a proposal. So we turn that into a set of actions and then we can ask people to volunteer for the actions. Right. Yeah, I think the main working group is a doom. If you're trying to attract technical people, because remember it started out it started out as the, for about 1 meeting as the operators working group. And then I change it, change the focus and.  The really it's not just the documentation because we do, you know, like the stuff that Brian is now getting into is more digging into technical things. I mean, I see it. I see us as more the community liaison or the community enablement group rather than documentations part of community enablement. So, I see us as the community enablement group. So. So, the other piece of that, and I think you guys are hitting on something that is like if you look at Kubernetes, they have the contributor SIG, which is all about onboarding people and creating ladders for contributions and that stuff. So I think we're on to something here too. The other thing is once you, if you do do the proposal that you're doing, and if we had a template for what people, what we wanted to ask of people, like if we had a template that we could give to CERN and say, here, tell us about your build process, put it into this templated form and structure. We could do that just once and have one good example. We've done in the past these hackathons. There are other community building tools like incentivizing people to share their stuff. We've got swag and backpacks and badging. Fedora has badges and stuff like this. There's stuff we can do that helps people get recognition. The other thing is to figure out how to get other maintainers, external maintainers on maybe we call it documentation, but on these GitOps patterns or the build patterns and different things. So that they're actually getting to be a contributor and getting to be a maintainer in this, you know, we could, I don't know what you want to call the group or how you want to structure it, but once we perhaps see the proposal and we had a template, because I know Jamie, you know, and everybody's, the hot stuff is GitOps and GitOps patterns and things like that. If we, you know, we could do some interesting things around that for deploying OKD and building OKD. And I think we could host a hackathon. We did that a while ago and that garnered me without templating, without a pattern that we wanted people to fit into for our documentation needs. A whole lot of really good insights into deploying and testing on different platforms and we haven't done anything like that in a long time. And now, you know, so maybe the outcome of this, and then to do get some marketing behind it, you know, to get some real marketing appeal, you know, especially if we call the GitOps or, I don't know, pick a good name.  Sorry, sorry. The other thing that I want to do is, I mean, I'm doing an extra gatherings. I want to use them as an outreach and a rec, almost a recruiting. So, if we can tell a story at the gathering of what we're doing in the short term, and if this is something you, you think is useful and want to help, and keep them a landing plate, OKD.io, just like a contribute or whatever. And I think we want to use every opportunity to sort of reach out and say, we are an open, welcoming community. If this is something that you feel is useful or valuable, come join, come help. So, here's my impression. Let me let me know if you folks think this is right. The people who are really deep and have the access to resources to spin up in AWS, etc. are the ones who are the most busy. The ones who would have the time and who are sort of the passionate folks starting out in this don't have the resources generally. You know, they're trying to do SNO or something like that. Would it be beneficial for us to find the resources to get someone to volunteer the resources for there to be an OKD cluster that folks can access who want to participate, play around in, or whatever. I mean, that gets into the whole issues of, OK, you'd have to administer it and whatever. But so many people seem to be stuck on being able to run it, a single note or whatever, because they don't have the resources, but they're interested in OKD, right? I think that is a, an absolute minefield because first thing you're going to get the cryptocurrency miners thinking free resource and but also I think, I mean, why I got involved in OKD is because I had clusters at work that I had user permission at, but I wanted to get under the covers. And when you're in a joint cluster, which comes to the point if we have a joint OKD cluster, you can't do those things. You have to be a restricted user. And the benefit for me of OKD is without having to either break the OpenShift license agreement and running a hooky version of OpenShift, I have a legal run time environment, which is very similar to OpenShift or the same as OpenShift, two manner changes. But I have complete control. I can trash it. I can do the what ifs. I can really get under the cover. So given that then, and actually, Bruce, you had something. You want to go ahead? Well, no, one of the thoughts that came to me is that in terms of sort of a hackathon with a catchy name is the phrase closing the gaps. Okay, because like we do have these gaps between OCP and OKD, which everybody is totally aware of. And with all of the red hat, watch what's cool this time with Edison and company. They're always using OCP. And that's probably like those videos would be a common place where people are going to have heard of us. And then they might come looking for, OK, how can they do that? Yeah. And they want to get beyond the mini cube demos. Right. So to circle around this though, like, do we need to really beef up the SNO documentation and tutorials? We need something if we if we're saying, OK, cluster is a bad idea, public cluster is a bad idea or manage cluster providing that is a bad idea. We need to make the entrance to running OKD in general very follow these five steps to get an SNO up or run this bash script or whatever like. Yeah, I mean, I'm hoping the effort on code ready containers. I mean, we talked about that one about a month ago where and I think there was something on Red Hat TV where there was a refocus on code ready containers. I'm hoping that does produce a a viable laptop experience, which still has the UI, maybe not all the security features, but it still has the UI and the dev experience, but it will run on a 16 gig laptop. So do we then it takes about nine, nine gigs to run? Sure. And now one of the things that you're not going to be able to run a big ID as well. Sure. But one of the things that we talked about is. Okay, but one of the things that we talked about as a group recently was we can't support CRC. Right, because we don't have enough people to we've been talking about, oh, yeah, we're going to do a doc or we're going to do whatever and we haven't really been able to. Do we hop on that thread that's in the discussion between the CRC folks. I don't know if you saw that it's like who is on that. There's a thread that's like multiple people. Some of them involved with CRC and some of them OKD. We're talking about this, this gap that's there. Do we hop on there and push on the CRC folks to get an OKD version out of them directly, right, because they were talking about there's some tricks that they could do and whatever. It seems to me that then if we can't do it ourselves then we need to put the pressure on to get a version put out with the OCP, you know, at the same time the OCP. The interesting thing is, if we do go center screen, I mean, Christian seemed to say that when we go center screen, we are effectively doing the same as OCP does in prowl for OPD. So the question then comes, if we go that way for CRC, does that mean that we get a free CRC out of prowl. That's a good question. That's a good question. Yeah, I don't know the answer to that one. That's a good one. And Christians in chat, but I can't, he's in a meeting right now, so I can't. Well, I'm looking forward to Dublin next week because I'm hoping that I can have a really good chat with Christian. Yeah, sorry that it was so packed last week that there's a lot of stuff we didn't get to because it was. The following week we'll have a deeper dive. Timothy will be back and we can ask more questions, but I don't think you can ask the CRC question out of Timothy. But yeah, hopefully, a few others will Fabiano and a few folks from the team that are working on this sprint. Yeah. Okay D on S cost will be there. Yeah, I mean, sorry, Jamie, I just want to go back to your previous question. I mean, I think something like the Red Hat Sandbox or the OpenShift Sandbox or OKD would help those that want it as a user experience rather than an admin or a contributor experience. So I think they would be merit in trying to replicate said like the OpenShift Sandbox environment for a user community that wanted dev. But then you ask the question, well, if it's the same dev experience, what are we getting? Yeah, that's what I that's a pushback that I get is that, well, if that's, if that's the case, just go use the Sandbox because the Sandbox is there and that's experienced. I think what you said earlier, Brian, about wanting to be able to get under the hood and crash and break things and stuff like that. That's different than a Sandbox or a developer trying to deploy an application. That's how do I break things, rebuild them, get to be a good to submit for this platform and understand, you know, how things break and rebuild themselves and all that kind of goodness. And that's the experience that we want to get. And you can't get that from any of the try before you buy stuff for OCP. Really, no CRC, you know, I'd say yes, but it's it's not real. I don't know. It doesn't feel like to me like a real, I use the word sis admin, so just shoot me if I'm using the wrong thing, but it doesn't feel like that that experience for me and the thing that that would make me really thrilled is, if like on AWS, there was all the images and everything you need to deploy OKD with either F cost or everything was there. And you could just go to a menu and say, OK, I want to deploy this on and here's my credit card or here's my university's account and I'm going to spin it up and then you get to play. But and that would be something that we don't really do for our product. It might be something, you know, that we that would be something actually Diane where a strip down version would help a lot because with the full version is quite chatty. And it's doing all of these monitoring things. And, you know, so you're going to have to update your credit card, you know, max balance pretty quickly, which is not great for students. I did an OKD and AWS. And just for testing what a base OKD install was and it was it ends up costing about 500 a month.  And that's not so. Yeah, that's like, you know, three control plane. And three workers, you know, that's the that's the default. And just to clarify, I wasn't thinking of creating a a dev workspace for just deploying applications, but instead like for doing pipelines for building components of of OKD and whatnot. So more like working group members having a space to do some of these pipeline things we've talked about in terms of assembling things, swapping out things using tecton to build OKD. Right. Exactly providing providing OKD to build OKD. So that that was the conversation that I was trying to have with people like Brian Cook and Marcel Hild and Karsten Wade is the community manager for operate first. They're in theory is a way for us to get that kind of access to have a cluster running OKD on the what's called Mass Open Cloud. It's I call it Boston University, their cloud that we have access to that we could have a build pipelines. We could do all of that stuff for it. And I think that's the conversation I'd like to pursue for the working group members. So maybe not the general public yet, like, but just for the, you know, you you belong to the working group. And, you know, you you get access to I don't know what the gatekeeping would be, but there is and they're keen to do it. You know, I, I'm keen to get them on a call with all of us to really walk through what the logistics of that looks like. And so maybe reaching out to and Brian Cook is really the technical person working on improving the build processes for OpenShift for OCP. And tangentially he's associated with the operate first team because they're all everybody's agent. But the operate first guys have a separate a separate agenda where they want to do other things and build patterns and pipeline stuff. But I those people I think if we can get them engaged with us are keen to work with us because they think of us as a really big community. And they, they, you know, it's all in perspective. Right. And I also almost I think as a way to justify operate first participation, you know, existing as an as an initiative. So we have an advantage there because we have some real needs and the people who do mass open cloud are all open shift people. They're very OCP and so I think there's an opportunity there. So I didn't try. I don't think I tried to pull in Brian Cook and the operate first people for the next OKD working group. But perhaps we should, you think I think that would be good. And I'll shoot a note to them now and see if I can get them on the next call. It seems like we've been sort of sitting on the idea for a couple months now. Yeah, it started before coup con. They came to me and we have been blathering on about it trying to get them to show up. And I know they want to. I think they may be an explicit invite. I don't know. Yeah, let's send it to him. Yeah. So, move on. So, Brian, moving back to technical documentation. Is there anything that you can glean from what Jack Enschel was talking about from CERN last week to inform our build docs or can should we meet with them and maybe pick his brain in a one on one or two on one. Yeah, I mean, he didn't actually give any concrete examples of the challenges they had to solve to get there going. He was more talking about I think their use cases. I think what will be really useful is to actually have the conversation of where did you struggle in building OKD. And just how much did they build and customize because I got I got the impression that, for some of it, it wasn't a lot of change. Right. But what he described was basically just literally taking the container list the container image list, pulling it down and swapping one out with what they want. You know, yes. So, so, yeah. So how was that like two containers or is it 20 containers or and what what challenges did they hit. And was it guesswork or was did they go through a process to actually figure out what the containers substitutions were. It was a pure guesswork. See, I think it'd be really worth while having that conversation with them. Do we want to set something up that's more informal then like just a quick meeting and yes, maybe come was prepared questions. Yeah, yeah, I mean whether we do it on Slack or whether you actually have a conference. Does it make sense to start with a discussion thread and have him chip in on a discussion thread. That way we can do it async in a spare time. Yeah, if he's willing to do it in the open, I don't know how he seemed very, very open in the meeting. I just don't know whether we would get into the technical details whether that's something they'd want to share or not giving it their internal. All right, well, let's let's reach out to him. I'm happy to reach out to him and just say what would be your preferred method of having a more technical conversation. And is he the the appropriate person there might be someone who's more did more of the actual hands on. Okay, I will add that as a task for myself. So, Amy, reach out to Jack. Okay, can I ask a question is related to what we've been talking about. So the. Partially it's not like I remember, you know, with, with version three cluster up and so on, which sort of got lost with version four. And when I'm looking at why things are so big. A lot of the stuff seems to be things that are required for an operational system that you don't really need for dev system. In terms of reliability and also monitoring. And then what's. So, you know, you need to pull some of that stuff up out. But if you try and do that what you immediately will find is that there's massive dependencies. If you try and pull out the monitoring all of a sudden your cluster, your console doesn't work. So then what I wonder on a technical standpoint is whether or not people have actually looked at the serve dependency graph. And if they've looked at the, the issue of how coupled everything is to everything else and whether or not you can decouple it so that you can actually pull out parts that you don't need and have the rest of it work. So, I mean, that gets into sort of a big technical question. And that's what I'm sorry. Go ahead. Yeah, no, I was going to say, and it may be that. If you're going to try and experiment on the outside, then, you know, maybe that's post building it the way it is. So, but I think that that was one of the things I was hoping that we would get into when we had this very brief CRC working group of how do we slim it down. And I thought that's what Red Hat were looking at. Because when, when they did the 410 launch streams, they did talk about reinvigorated effort around code ready containers. I think they've even rebranded it and we keep calling it CRC but there's another name and it's escaping my brain right now, but they have been re looking at it but not in the context of. Okay, they haven't been a conversation but and slimming it down. Frankly, the focus right now is on micro shift, which isn't, which is not really what we are. No, it's not the user experience that we want now. Yeah, is anybody Diane looking at the, like, what would be the benefits of Microsoft versus the 15 other Kubernetes alternatives. You know, like Kubernetes and Docker or.  I'm sure there is some sort of competitive chart somewhere. Yeah, we talked about this, I think at the last meeting is that I don't think that there, there is one readily available. I don't think there's one in the OKD community or the open shift community, but I'm sure outside of the community that there are. Yeah, I also think that micro shift is serving a different master. It's serving the edge computing telco automotive reaching to the very edges of devices and things and needs, you know, it needs bits and pieces of Kubernetes, but not all of it, just like you're describing there. So, but I think we have different needs for different bits and pieces, especially the developer experience pieces. So, I think whatever code ready containers or snow comes out to be. Or if we create, you know, the other thing is we could hack our own slender, you know, the slender man version of OKD as a community if we wanted to, especially if we owned our build process. Just like if we could get on, I mean, this is the I was shutting down so I could log in and see if I could get everybody to talk about the upper if we had our own build process. We could have build pipelines for lots of different things for generic OKD on a Fedora Core OS, something for open stacks similar to what has done something for Mike McEwen's project that he's looking around. So the goal here, I know we keep looking back at the mothership at Red Hat to do something for a slender, but it might be something we have we'd have to hack and build ourselves. Hack out everything you don't want, Bruce, and, and see if we can make it work.  Yeah, maybe we have to stub where things aren't there. We can't change the OpenShift OCP source, so we may have to provide a stub to allow us to remove a component, but still have everything else work as it was there. I think we can learn a lot from the approach that CERN took to make it work, you know, what they had to do to customize it to work with their version, their flavor of open stack. And that's what I'm hoping. And anyway, I digress and I will go send that email and get the appropriate first people on all next week. All right, let's move on real quickly. Repository move timeline and steps. Doesn't seem like anyone else has added anything in terms of discussion to that item. Do we want to just move forward with the handful of us doing this work or do we want to get more people? Well, I think that I think the big one is the OKD repo, because that's where we've got our discussion. And that's where everyone's been pointing to so I think we're going to have to manage the migration of that one. I did an experiment and worked out if you transfer ownership, then everything goes with it. So I think we know how to move it now. But it's going to be that how do we manage getting everybody that we've just got going to the discussion forum there. Over to the new discussion forum. So that's the challenge there for the OKD.io one, we just need to coordinate with whoever looks after the DNS to make sure that we get that synapse switched over to on project. So in terms of the other OKD repo, Vadim just enabled discussions. That's actually a relatively new thing. There wasn't discussions before. We could just say to Vadim, hey, can you shut this down? You know what I mean? Like we want people to go through. Once you transfer ownership, it goes. Once you transfer ownership, it will all be in on you. So we're just going to move everything that's there across. But it's if people have bookmarked it and now I think if nobody else grabs the name, GitHub will do an automatic redirect for a short amount of time. But it's it's more about we don't want to disconnect everybody that's in the community. So I think there will have to be some messaging around. This is what we're going to do and this is when we're going to do it. So to give people a chance. Well, we had set a timeline of July 1st. I think that's optimistic in terms of messaging just because QCon took. So much time out of people and we had the jam packed main meeting. So let's actually I'll set aside 15 minutes at the next main meeting. To talk about this and actually make sure everyone is aware that's the biggest thing is awareness that everyone in the working group is aware. This is really happening. We've been talking about it, but it's really happening. Yeah. Yeah. Alright, moving on because we've got about 12 minutes left. Survey will go out tomorrow in all the places I'm going to post it in. And let me see if I've got this right. Anyone let me know if I've missed anything the slack channel. Diane, do you have control of the Twitter at least. Yep, I can treat. Okay, so the tweet will go out. Should we put a blog posts on the website for on okay.d.io. Yeah. Let's do a blog post for that. Well, rather than that put on the front page. Yeah. People might not find the blog. Let's just put it on as a title. That's my page a block. Yeah. Okay, let's do that. And then do we want to have a set time that we keep it up. Or do we want it to be indefinite? Keep it up for as. Yeah, keep it. Make it indefinite. I would say. Because we can just keep gathering data from it. As we go, you know, the other thing is the talk that Brian and Christian are going to give in Dublin is going to be recorded. So, Ryan, in, in whatever you do, think of that as something that's going to get embedded into the okay.d.io homepage. Okay. So as you're talking the, you know, because I really capture that content. The freshest stuff with the S cost conversation in it and get that on the homepage as well. Okay. Yeah. I need to work out what we're going to say and who's going to say what so I need to get together with Christian and work out what needs to be said at that event next week. He just booked his stuff. And then when in London, he's not going to go. And what we might end up doing is just the 10 minutes sprint version of what you guys do for the half hour there and just have you on stage. Talking about and basically recruiting again. So think about it that in that way we've done both versions, but I really would like the in-depth one for get a half an hour. So use it. Okay. Okay, next up is the, are there any other fact suggestions? I've got those there. I'm sort of chipping away at them. Does anyone else have any suggestions for frequently asked questions that we should ask? Or that we should add the answers to. Anyway, if you do, please add that maybe I'll do a discussion item that's like people can just throw suggestions into it. Like, okay, here's things. SNO documentation. Nothing, nothing. I don't think there's any more discussion on that. That's an important point from what you were talking about the first item at the minute we don't have SNO on the site. And I think that's really important because that means that we nobody can do a reduced resource install of okay D now. Well, let me see. I think an ask of the main meeting is somebody that understands the new process. Yeah, needs to write the instructions. And I'll see Michaels on and needs to work with Michael to get those instructions into the docs. Yeah. So I think that's an ask of the main meeting. Okay. Well, I will add that to something to ask at the main meeting. Depersonalizing homelab documentation. Are we just going to do we want to just go and change these or do we want to reach out to the demon tree? I haven't seen shrie at the last meeting or so. No, you should message. Yeah, I'll be update his stuff and and of course the team we can. Is there a better descriptors Brian for that other than Vadim's homelab and trees. Well, I think, I mean, I'd like to know what value they provide. Not not not not in a nasty way but because when I see the word guide. I think it's going to guide me to do something or help me do something. These are literally example installs. They're not guides in any way they are just, this is what you can do with okay D. It's an exemplar of uninstall. So maybe create another heading that is example installs and then but also take the depersonalize it a little bit and you can keep in in the heading and just keep it you know who the author is and everything like that but that if that I'd be more comfortable with that as well. And this goes to like getting a template for people to use and reuse to so. But I think I think example installs is a good thing and then we can go get out. How about example installs and configurations because it's more than just more than installs it's there's also like how I run it type stuff and I was going to say there's also some an issue with. With currency, because I think I think it's the deans, but he went and did a hacked single node install before single node install was there because these are these are version four five or four six, not four 10. Brian, does it make sense then for you to pull these out until they are updated. Well, I or moved around or manipulated in whatever fashion. I mean, it comes back to getting content from the community. I'd like, I'd like that to be proper guides. I mean, we're not. But if these are outdated and if they're not helpful right now, does it make sense to hide them until we possibly. How about this. We add the menu item, drop them into just call it examples and then have whatever the title is, you know, not vetting, whatever. But have them there so that we don't lose the legacy and then make a request at the next meeting to see if there's anybody who's willing to take vettings document document is example and try it again. Right now that we have snow and then make and. And well, again, we need the template. We need a little bit of better turned and look for a volunteer to take what that even did and what Sri did. And turn it updated try it for the new thing and give us feedback and update the docs and. You know, I have, I have swag. If I need to send them an open shift backpack. I would do that.  I think that's trying to incentivizing people a little bit here. Yeah, I mean, as an idea. Is it worth trying to do a working like like a hackathon or work because I mean Daniel was sort of started taking on that but never really did anything but I think we need to actually, again, looking at that how easy is it for someone to come on board. I couldn't, I couldn't get on board with what the information that's on there. I ended up watching a YouTube video. Yeah. And because even with the doctor IO, it was taking me through the configuration and I didn't know the cabler I didn't have a terminology. I look at it now and it makes sense to me, but the very first time I did that. I didn't know the vocabulary. I didn't know the domain. I didn't know what it was asking me for. So I went and found the YouTube video. And it showed me exactly what I needed to do. I could pause the video and say, oh, that's what that value means. And so I think it is worth just going back and maybe having a workshop. If we can get enough people, four or five people, and let's do a two, three hour workshop, and let's define what a guide needs to be for each for a platform, create a template, and then we can go and ask for volunteers. Well, Brian, this is actually this predates you but we did that. What was it two years ago? Or yeah, I think it was a year and a half ago. Maybe it was like maybe the last winter. We did something like that. And it actually this work that you're seeing was sort of spawned out of that and the guides were sort of spawned out of that. And that was the effort when we started to sort of migrate the guides from the one location to the other came out of those guides sitting there for a while. So Diane, can we set something up in August? I would love to do something in August. Yeah, because that would give us enough time to publicize it. So if you want to look at your calendars, including Michael Burke, because it would be lovely to have a documentation person on around and see what dates and just let me know and maybe think about it by next week. We could socialize a date and I'm happy to use BlueJeans or Zoom. Zoom, you can have breakout rooms and stuff like that and host it. We can even do it using, not HackMD, Hopin. Again, because that just have four tracks or whatever, one big track and then spawn up new tracks as we need them in Hopin. And then we'd also capture their names and everything else for future recruitment. Hopin was what we used last time and that turned out to be really helpful for that. Yeah, I'd be happy to do that. Just pick a date. I will look, I'll just say that I'm going to be busy mid-July, so August I love. I'm moving my mother to Canada, slowly but surely. And hopefully by August things will calm down. So we'll get that. I'd love to do that. I'd be happy to do that and start to do a cadence of things along that line. I think we also could have a Hack, not a Hack, a Hopin hackathon on testing the CentOS dream deployment. So we're in theory. I'm probably not supposed to say that that's going to come around July 15th ish, but that's very and practice is something else. So we'll hear it. We can ask Timothy, but I think right after that's out, it would be nice to have a hackathon on explaining how to, you know, the differences, if any, and how to get it and do something. Some publicity around that to see who does it and I haven't heard. Anyways, now we're at the end of our hour. Yeah, so we're at the end of the hour. What I actually had as costs as an agenda item, I'll bump it to next documentation meeting. The gist is going to be, we should probably have a conversation of how do we talk to the community about it. Right. And I don't think we have enough details yet to be able to talk to the community about what we're going to want to. And just so, you know, what I have asked is Michelle Crickey and. Aviano and that team to write a blog. And with Timothy and Steven about the coming of S cause, not in relationship with okay D. And then a follow on one in relationship with that. So, and maybe highlight the work that the folks who are in the sprint to the engineers and get them to come. So my goal is Fabiano probably will show up again next week. I'm hoping he drags Luigi and there's a few other folks on that team that are doing that sprint. I really need them just to get engaged with the okay D working group on an ongoing basis. I think the more we love them for what they're doing, the more likely they'll want to stay invested in and it will, they'll be invested in it. For a while, but again, I don't want to burn people out like we've done with that even though all the support and love we can show them for the work that they've done. And this is probably their 1st attempt at doing anything with okay D the guys and gals that are working on it. It'll be fun. Packathon date. Let me know. I'll set up the, we'll talk about it next week's meeting. And then I'll set up hop in and host that and we can do it for 4 hours or a whole day. That's what it takes. Awesome. All right. Well, we're over time. So let's call it. Call the meeting now and I'll see most of you all next week. Right. Cheers.


All viruses, including SARS-CoV-2 that causes COVID-19 disease, mutate over time. Most mutations have little or no effect, but some can influence properties of viruses, including how easily they spread, the severity of the disease they cause, and their resistance to vaccines. Since the COVID-19 outbreak first began in Wuhan in late December 2019, the evolution of the causative agent SARS-CoV-2 has led to variants of concern and of interest. A variant of concern is one for which there is evidence of an increase in transmissibility, more severe disease, example increased hospitalizations or deaths, significant reduction in neutralization by antibodies generated during previous infection or vaccination, or reduced effectiveness of treatments or vaccines. These are the alpha, beta, gamma, and delta variants. Variants of interest are those associated with reduced effects of the antibodies generated against previous infection or vaccination, reduced efficacy of treatments, or predicted increase in transmissibility or disease severity. Current variants of interest are eta, iota, kappa, lamba, and mu. Variants of concern in St. Lucia, alpha. The alpha variant is also referred to as the UK variant as the first cases we've seen in the United Kingdom. In St. Lucia, the alpha variant was first identified in mid-December 2020 amongst locals and one UK resident. Observation of our epidemiological curve indicates that this finding was the trigger for the increased number of cases experienced during our second wave which lasted from December 2020 to February 2021. The alpha variant can also be considered a de-escalated variant as it has been circulating for a while without any impact on the overall epidemiological situation. To date, 54 cases of the alpha variant have been confirmed in country. Delta. The delta variant also referred to as the India variant. The delta variant was identified in St. Lucia in mid-August 2021 and since then we have seen an exponential increase in infections and mortality. This is consistent with data from other countries which show that, one, delta thus far is more contagious. The delta variant is highly contagious, about 130% more contagious than previous variants. Two, the delta variant might cause more severe illness than previous variants in unvaccinated people. External data shows that the vast majority of infections, hospitalizations and death is amongst unvaccinated people. Three, unvaccinated people remain the greatest concern. The greatest risk of transmission is among unvaccinated people who are much more likely to get infected and therefore transmit the virus. Fully vaccinated people get COVID-19 known as breakthrough infections less often than unvaccinated people. Four, fully vaccinated people with delta variant breakthrough infections can spread the virus to others. However, vaccinated people appear to spread the virus for a shorter time. To date, three cases of the delta variant have been confirmed in country. The Mu variant. Mu, which was first identified in Columbia in January 2021 and is known scientifically as B1.621, was classified earlier this month as a variant of interest by the World Health Organization. The Mu one being potentially more of concern because of the potential increased immune escape that it may show. Though there is not much data on the Mu variant, the epidemiology unit in the Ministry of Health is monitoring the data on this variant as it has been identified in the neighboring islands of Grenada and St. Vincent. The Mu variant has not been identified in St. Lucia. Despite all variants that exist, the data informs that the best protection in the fight against COVID-19 is the vaccine, coupled with the protocols of washing hands frequently, wearing a mask in public places and social distances. Failure to adhere to this advice will result in the increase in infection, hospitalizations, and death. The Ministry of Health continues to advise persons to vaccinate and follow the protocols so as to give them the best chance against this virus.


아 졸려 굿모닝 Assalamu alaikum warahmatullahi wabarakatuh 안녕하세요 다우도 김입니다 I will make the video What if a Muslim stay home whole day Quarantine vlog So that's why I turn on the camera At first, I should wash Okay, I will take video later 네, 씻고 왔습니다 So it's time to pray So I washed and prayed So I think it's time to clean up 왜 이렇게 더러워? I didn't do anything But my room always messed up I don't know why Let's clean up first 빨래 할 겁니다 빨래 할 때 없어왔네 네, 어느 정도? 끝난 것 같습니다 네, 잠시만요 그 앞에다가 놔주세요 My grandmother gave me food You know, I cannot go outside So now my grandmother made food for me Breakfast 그러면 잘 먹겠습니다 I should take the temperature The health care gave me guideline paper garbage bag this is a lot water temperature check 이겁니다 I should wait one minute one minute 36.3 Okay, so today I will listen Our Ana In the name of God, the gracious, the merciful Praise be to God who created the heavens and the earth and made the darkness and the light yet those who disbelieve ascribe equals to their load I will show you how to edit I edit like this As-salamu alaikum Annyeonghase, I'm Dr. Kim 지금 자아경리한지 3일째입니다 Subtitle and cutting and editing and coloring Everything that I need I do with Premiere Pro Actually this is spring So there is a cherry blossom festival outside Of course the festival is very small this year But I want to see flowers I really like flowers 이제 또 뭐 할까요? What should I do next? Exercise 아 힘들다 자아경리의 좋은 점이라면 글쎄 하루 종일 누워있다는 거? So there are not many special things nowadays But I think it's really good opportunity too I have a lot of time to read books starting Quran and focus on praying and think about my relationship with Allah So I think it would be really precious time for me Thank you for watching my video Take care and be safe Alhamdulillah As-salamu alaikum Be safe Stay home Bye bye


I think the biggest myth about the House of Lords is that it is a lot of old men, dressed in ermine robes, sipping tea and that they're all hereditary and that couldn't really be further from the truth. I came into the House of Lords in 2004. My background is in international development and human rights and I think that that is always a useful skill to have when one is debating and revising legislation which after all does affect people and their lives. I get to work at House Lords between 8.30 and 9. In any one day I might do several of the following. Have meetings. I meet with the political leaders in the House of the Chief Whips. I meet with the senior authorities in the House of Lords. I meet with individual peers who come in to talk to me. I meet with school children. I will meet with various interest groups. I most probably will meet with the speaker of another parliament. I then sit on the wool sack. Now this is a major part of my day. I process through the house and I follow the mace into the chamber of the House of Lords and I open the house. So I'm always in the house when all all questions take place and this is the most lively part of the House of Lords day. And then in the afternoon I might have a foreign ambassador come see me, a foreign speaker. In the evening there may be probably two or three receptions. The speaker also has a ceremonial role. For example, when the Burmese political leader of the National League for Democracy on Sansu Chi came to address parliamentarians and I was able to give her a vote of thanks and I will make a speech of welcome or whatever it might be. Just sort of add a little bit of glamour let's say to the to the state visits. So it's a very, very full day and I very rarely leave the house before let's say 9, half past 9 in the evening. I would think that the majority of my day is spent having conversations with people of one sort or another. Talking to the public at large and then school children in particular and different groups is rewarding in part because it means that you're in touch with the wider community. I learn how current legislation is actually affecting the work that they do and to some extent I can feed that back because during my day I tend to meet all the political leaders in the House of Lords. I'm constantly exchanging views with them and hearing what they have to say but also expressing my own views which I've gathered in talking to those groups. The thing that really is very heartwarming is to watch the way in which individual peers in the House of Lords have such extraordinary expertise and you're working together peers from all the political parties to achieve a particular outcome. And I think what it demonstrates is that the House of Lords is predominantly concerned with issues rather than with party political matters. So it is driven by the content of bills rather than the fact that it has to vote according to a party political dictum. I really do feel it's quite a privilege to be able to be on the inside of political decision making of watching how politics progress, how bills are achieved and how they affect the wider community.


All right. So we're good. Well, thank you everyone for coming here. So some of you don't know me. My name is Cédric Honnet. I'm a research engineer in embedded systems applied to human-computer interaction. I work at this university over there. It used to be whatever. But I work on this project called Hive Tracker, which is a miniaturization of this big thing that basically allows people to 3D position objects in virtual reality. So this project is in partnership with a lab in London from UCL. They're like a neuroscience lab. Another lab in Spain. Also kind of neuroscience. And I'm more in the robotic side. So the context is virtual reality. I think all of you know HTC Vive. Ah, we have a late person. All right, that keeps going. So any of you doesn't know the special aspects of the HTC Vive? You're all good with it. They're basically positioned in 3D. So you know exactly where the head of the user is. You know where their hands are. And so it allows you to do very surprising things in 3D. If you've never tried it, it's really worth it. I recommend. But the problem is, if you want to 3D localize something like a hand, you see the size of an object is like an orange. So you cannot track everything you want. I'm going to explain a bit what we want to do with it, where we try to miniaturize it. But I think the most interesting part of what I can show is how this thing works because it's pretty smart. And how we went from this range that we just saw, a big object to a much smaller object. So basically, a bit like the GPS system, you have lighthouses that are generating an infrared lasers. Yeah, infrared lasers. And you can localize yourself according to their signals. The way it works, basically the infrared laser goes through a lens that diffracts it and creates a nice line that either scans horizontally or vertically. So to simplify the way it works, you have to imagine that you are maybe somewhere, let's look for example here. So if you know that you are somewhere on this line and you want to localize yourself on this line, you have to imagine a lighthouse that sends a double flash to say, I'm going to start counting. And then you imagine the scan that comes, and when it hits you, you can calculate the angle between, let's say, the zero at my left and where you are somewhere on this line. So if you know exactly where you are on one line, because you counted one, two, three, you have an angle, maybe 30 degrees, if you know how to do that particularly, you can have two angles. So you do a scan horizontally and a scan vertically. And with two angles, you can estimate your position with a line, a kind of vector coming from a base that could be, as you can see on the animation at the corner of a room. And this line points at you. But if you are in three dimension, one line is not enough, you need another one. So you are at the intersection of the two lines if you have another base. So basically what we see is one of them, but you need two. So the idea of this project was to convert time in angle as I was explaining, like the three microseconds could be for example 30 degrees. So you have this flash that I was talking about, it's like a double flash to say start and then you count one, two, three, and then there's another flash. Did I touch something? No? Okay. Is it well, Alex? All right, very good. So we have one angle with one timing, one other angle with the other timing. And that's for, it looks like it's three bases, but it's one base. And so one base will give you one line in 3D and the other base will give you the other to have the intersection. So we can count the time, I'm not going to go through those timings, but basically they are very accurate and very fast timings because the idea is to localize someone in 3D with a quarter of millimeter accuracy five meters away from the base. So the first prototype used only one photosensor that is receiving the laser signal that I was just talking about and microcontroller that's pretty fast, some of you might know it, it's called the TINSI, the board is called the TINSI and the microcontroller runs at 120 megahertz, so it's 120 millions of instructions per second, which means that we're fairly accurate. The problem is that if you have an object with only one photosensor, when it's not looking at the base, you don't know where you are anymore. So you need at least four photosensors so that with this kind of tetrahydric shape and if you are in any orientation possible, you always have one photosensor that can see the base. But you have to be able to measure the timings for the four photosensors. And if you want to do that, normally you would do it with some very complicated electronics that I'm going to talk about, but I don't know why this slide is here, I think I should move it, but basically what the first prototype did was to do some kind of 3D graffiti and some of the applications of what my lab wants to do are documenting unique and maybe dying handcraft traditions in something like the maker space of the future. The lab in England that I was talking about, they want to track rats and put electrodes around their brain so that they understand what's happening when they're changing their path. Many other applications are possible but there's this list, whatever. So if we go deep in the details of the timings, which I'm not going to do right now, we can see how accurate we need to be and how we need very particular processors. So is anyone here not very familiar with the concept of FPGA? Some of you are not there.  They have to do things sequentially. And you have to imagine the code that you put in it is a bit like any script that you would give to a theater actor. When you give code to an FPGA, it's more like the DNA of the electronic circuit that you want to give birth to. You have to give it what it has to be, not what it has to do. It's a really different way of approaching the problem. So those components are usually pretty big but if you dig around you can find some pretty small ones. So there's this project that you might have heard of on Hackaday that made a really tiny FPGA development board. So we could put that on this board. It's not impossible but if we find a way to avoid it, it's even better. So digging in the datasheet of this magic microcontroller, the NRF 52 by Nordic Semiconductors I found that there is a kind of FPGA that allows you to connect things in hardware and do real parallel processing. So as we have four photo diodes listening to all of the lasers coming from everywhere we want to be able to parallel process these signals and give them a timestamp. And if we don't do that really in parallel with the common way to do which is doing an interruption, timestamp the first, doing another interruption, timestamp the second and so on, you lose accuracy because the time that you spent doing the first timestamp will delay the second, the third, the fourth and you don't know which one came first in the next ones. So this magic thing, PPI for peripheral, I forgot what, interconnection I think it's peripheral-peripheral interconnection because basically you can connect digital input, GPIO. Programmable peripheral. Thank you. Programmable peripheral, whatever, interconnection. So you can connect GPIO, a timer, many other peripherals. The idea here is to just connect the photo diodes to a timer and measure the timings. So I use this magic little microprocessor that we can see here. All the details of this board are on the website. But basically this guy is pretty smart because it has the microprocessor, the Bluetooth communication module, the antenna, all of the components that you need to make it work like the capacitors and the two quarts, one low frequency when it wants to sleep and be in low power and one high speed to do the radio communication. This other guy here is a 9 degrees of freedom motion sensor so it can measure its orientation, its accelerations and it does the fusion inside. It's a Bosch processor, IMU, that has a processor inside. Hi! And then the rest is not so important here. It's the power supply, LED, button. And then on the other side, we have the connectors to put the photo sensors. So we're going to see it on the next slide. But basically that's the board once it's done and it's about the size of one Singaporean dollar coin or one pound coin or... I don't know, for the US dollars, whatever. Probably smaller than a quarter I would say. So to give another scale, after the assembly it looks like it's the size of a sort of one of my fingers. And so the photo sensors that I was talking about, they have... So it's actually a circuit with the photo sensor itself and a bit of electronics made by a company called Triad Semiconductors that help to do all the filtering, the amplification and the digital communication. So this is just the first step that makes it easy to develop. So I just have to put connectors to top this slide. It's not very obvious but those things are flexible so you can put it in your 3D object if you 3D print it or if you put it anywhere like a candle or I don't know. It's flexible, it takes the shape you want and it can be shorter or longer. But the next step that would be interesting I think would be to have almost the same object but instead of putting connectors like these we could put the photo sensors directly on the board and give them the exact orientation that we want. So these guys are through-hole. It means we can solder them through-hole or we can solder them on top also. But once they are soldered on top we can bend them and they keep their orientation. That's the interesting part. I think I can stop here and if you have more questions I have a lot more things I can show. If any of you has any question about how to integrate that in virtual reality or how to make boards because I understand that some of you have. So you can contact me on Twitter on that. Otherwise the website here has all of the hardware, the firmware that is in progress. And I think that's it. Thank you for your attention. When you say it's in progress, how far is it? That's always the hardest question, right? So the way you analyze these timings from the lasers is a bit tricky. You need a kind of state machine that's using interruptions and this PPI mess the special hardware that you only find in this processor. So all of the fundamental blocks are pretty much done. The state machine is done. I had to modify the Arduino environment so that it works with this processor because the idea is to make it as simple as possible so that anyone can use it. So the Arduino environment modification is done. All of the blocks are made. So technically it should be fast. In real it's probably going to be a bit painful. I would say a couple of months at least. One of the interesting next steps is to use some smart filtering like Kalman or an improved version to use the integration of the acceleration measured by this sensor so that we can accelerate the positioning estimation because for now we have about 30 Hz refresh rate of the lasers because even though they are going super fast you cannot do much faster than that. And 30 Hz is usually good but when you do a fast motion the accelerometer could do a good extrapolation of the positioning in between this 30 Hz refresh rate of the optical sensing. So that part is a bit tricky. I have a few students working on it right now. I'm lucky I can have slaves. They are really impressively fast and it's quite cool to have them. And the next step is I'm probably going to have an intern for six months working on that also. So across fingers this should be at least done in six months. You want one? Any other question? Can you tell a bit more about the applications? All right. So the question is if I can talk a bit more about the applications. So as you can see this is probably small enough to put on a wrap. It depends on how big a wrap you have. Exactly. It depends on your right. I think you have big rats in Singapore. We do. Well lab rats should be okay to carry that. Maybe Singaporeans could have bigger, with bigger batteries. Yeah, there's the battery that comes with it and the photo sensor that we saw but it should not be much bigger. I think from what I understood I'm not a neuroscientist but from what I understood by those guys the Chemflab, they want to understand what's happening in the brain when you are in front of, for example, a food predator or your board or this kind of thing. And the orders that you give to your body to your limbs to move around as a reaction to what happens around you it's not completely clear how it's working and some animals are easy to analyze. They are pretty rare. Are you familiar with the cuttlefish? So for those who don't know it's a very surprising animal, a bit like the chameleon. It can change its appearance. To me it looks a bit like an eating display. It has a lot of pixels on the back and it's really surprising when you put food in front of it it has this kind of warrior mode it changes its color. It's like I'm going to fight to get that food. And when it catches it if it's trying to get it and it's frustrated because it doesn't come you can see the frustration on the back. It has frustrated return on the back. It's really funny. And then when it gets it, it's like happy. It's just return on the back. So this cannot be done with rats. Not as easily. They tend to change colors sometimes. Like you get red when you're angry or green when you're cold all these kind of things. So that's one of the experiments that are done by the lab that started this project. The micro manipulation part so the third dot here is about how to grab things. It doesn't have to be just like surgery or watchmaking can be like how to grab an atom and feel it with a haptic feedback like a tactile resistance. So there's this Teletweezer. It's a project of the lab where I work at Sorbonne. And they are basically localizing in 3D with big sensors using cameras. The position of a tweezer and it gives you a feedback of what you're grabbing and it knows exactly where it is but it's really big so it's not very practical. And on the other hand it's remotely controlling a robot that is grabbing things or a laser that is actually controlling the position of an atom or weird things. So with this stuff you have like one of these fingers? So it's just a tweezer with a sensor at the end. So you know your orientation and your position would be a bit simpler. The 3D haptic texture mapping is more for virtual reality when you're trying to either touch things that don't exist. How do you feel like this is maybe you're in front of a wall it's in bricks or it's maybe in carpet or in foam you can maybe go through it this kind of thing. We can create haptic illusions and make you feel like you're touching things that you're not using special vibration patterns. And the last one they are performances are how to visualize or sonify the movement using this kind of sensors for example with dancers but it could be any movement like a graffiti artist doing his motion could create sound on top of the visualization that's already created. And if you have other ideas we can talk about it. It's still in progress but when all of these things will be working they will be published either on my account or this website. Any other questions? How does the sensor use when the laser start to scan? The timing when the laser starts and the timing when you use it? So it's a pretty dumb sensor as you can so the question is how does the sensor knows when it starts scanning? So here I didn't explain it so well but today it's the superposition of several chronograms coming from several photosensors. So here you can see there's four photosensors connected to this board this is the official development board by trite semiconductors. If you graph the signals that you get from them you can see the colors for several sensors and they basically all start at the same at the same moment and this is because the two bases they synchronize each other one of them is the master basically and the other is just the follower so the first one will do a flash and then the second will do another flash No sorry I'm talking shit the first one will do a double flash and so this is for example for one scan like the vertical scan one of them so it will do a double flash saying I'm going to start now so you should start counting and depending on the length of this you can estimate I mean you can decode using the length you can decode are you going to do a vertical horizontal scan or are you going to flash from the base A or B and so once you have that you have the scan and then depending on the sensor because they are not placed at the same place you will have a pulse at a different position because different position in real time then this will happen again the same thing will happen another time but instead of being vertical it will be horizontal and the start signal will look almost the same except it will say now it's not vertically it's horizontal and then the second base will talk and will do almost the same so I have to double check I don't remember by hand but I think yeah this is base A and this is base B and you can differentiate them and this is like 400 microseconds but basically you have to create a state machine that looks for a double pulse and because this would if you look at only one sensor for example only the red this is not a double pulse with the correct length so you have to look for this exact patterns with different it's a variable double length it's a bit of a pain I can show you more if you want after what if there is any other question maybe there's no so would you like to show your project a bit I think other people would be interested it's everyone what do you think we can just put everything on the table sounds good to me