Hello, everyone. This is the Circuit Python weekly meeting for August the 29th, 2022. This is the time of the week where we get together to talk about all things Circuit Python. My name is Tim and I am sponsored by Adafruit to work on Circuit Python. Circuit Python is a version of Python that's designed to run on tiny computers called microcontrollers. Circuit Python development is primarily sponsored by Adafruit, so if you want to support them and the Circuit Python project, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join anytime by going to adafruit.it slash discord. We hold the meeting in the Circuit Python Dev text channel as well as the Circuit Python voice channel. This meeting typically occurs Mondays at 2 p.m. Eastern, 11 a.m. Pacific, except when that coincides with a U.S. holiday. In the note stock, there's a link to a calendar you can view online or add it to your favorite calendar app. We also send notifications about upcoming meetings via Discord. If you would like to receive these notifications, ask us to add you to the Circuit Pythonistas role over on Discord. There is a notes doc that accompanies the meeting and recording. The notes document contains time stamps to go along with the video, so you can use the doc to skip around and view the parts that interest you most. After each meeting, we'll post the link to the next meeting's notes document in the Circuit Python Dev channel on the Adafruit Discord. You can always check the pinned messages there to find the latest notes doc throughout the week, and you are free, of course, to add your hug reports and status updates throughout the week if you think of them early. If you wish to participate but can't attend, you can leave your hug reports and status updates in that document for us to read during the meeting. On to the meeting structure. This meeting will get held in five parts. The first part is going to be community news. This is a look at all things Circuit Python and Python on hardware from in the community. It's a preview, a sneak peek, if you will, of the Python on microcontrollers newsletter. The second part is the state of Circuit Python, the libraries in Blinka. This one is a statistical overview of the entire project. The chance to look at the project by the numbers separate from what we're all up to. The next part is hug reports. This is the first of our two round robins. Hug reports is an opportunity to highlight the good things folks are doing. Take time to recognize awesome folks in our community and beyond. The fourth part and final round robin section is the status update section. Status updates is an opportunity to sync up on what we've been up to. Take a few minutes to talk about what you've been doing since the last week and what you plan to work on in the next week until the next meeting. And then the fifth and final part rounding things out is in the weeds. In the weeds is an opportunity for more long form discussions. These can come out of status updates or they can be topics identified ahead of time as too long for status updates. So that covers how the meeting will go. So we'll get into our first one of those sections, which is the community news section. This week in community news first item we have is check out the simulator in beta for the micro bit Python editor. Simulator is now available within the beta micro bit Python editor. This allows you to try your code before sending it to the micro bit. The developers are fine tuning it over the next few weeks. So send them feedback and help make it even better. This comes to us from the micro bit newsletter and there is a link to that in the note stock for the meeting. And of course this will be in the newsletter when it gets sent out tomorrow. Next up we have the micro Python form migration over to GitHub discussions. So after close to nine years the micro Python team has decided to close their form in favor of moving over to GitHub discussions. We have a link here to the actual micro Python form post as well as a link to the new home for these discussions over on GitHub. Next up we have Py bricks Python for Lego. Py bricks is Python coding for smart Lego hubs run micro Python scripts directly on the hub and get full control over your motors and sensors. Py bricks runs on Lego boost city, technic, mind storms and spike. You can code it using Windows, Mac, Linux, Chromebook and Android. It's released under MIT open source license and you can find more information at pybricks.com. Next up we have editor news. There is a new I believe plug-in for VS code. So VS code is going to be able to upload your code using the new circuit Python 8 web workflow. Luke Williams is working on a task definition for, excuse me, task definition and Python script to upload from VS code to circuit Python boards via the web workflow rest API. It's a work in progress at this time. It shows how leveraging new features in circuit Python 8 can help development. And this is a project which is being hosted open source out on GitHub. So there is a link to the GitHub repository here in the notes and newsletter. Next up we have a new version of Thawney. This is a Thawney version 4.0.0. Thawney 4.0.0 has emerged from beta with many changes and fixes. A main change is that they have dropped support for Python 3.5, 3.6 and 3.7. There are about two dozen changes for micro Python and circuit Python. You can learn more on the Thawney releases page over on GitHub. Next up we have whippersnapper news. Whippersnapper has implemented custom component visualizations. Adafruit has introduced some new gorgeous default whippersnapper component visualizations and the ability for users to customize them. This comes to us from the Adafruit blog. So there's a link there to the blog post to learn more. A few of the features supported with us are custom labels, custom icons, component contributors can set their default visualizations as well as I2C sensors displaying the appropriate SI units. There are some new sensor types as well and again you can find more information on that over on the blog post. The last one this week from around the web, a project from the community. This one is a dragon frame clock. This is built with a Pimeroni hyper pixel round display and a Raspberry Pi Zero W. It runs with Python and I thought this was a really, really nice looking clock display so I couldn't resist adding it to our Notestock here for today. This is linked out on Twitter and this comes to us from talktech.info, the username on Twitter there. So there's a link over to Twitter as well as an image if anyone's interested in that. All right. So that gets us through the news items. I will wrap it up by telling you a bit more about the newsletter itself. The Circuit Python Weekly newsletter is a Circuit Python community run newsletter. It's emailed every Tuesday. The complete archives are available on AdafruitDaily.com. It highlights the latest Python on hardware related news from around the web including Circuit Python, Python and MicroPython developments. To contribute your own news or projects, you can edit next week's draft on GitHub. You can submit a pull request to the Circuit Python Weekly newsletter repository. Or if you'd like, you can also tag a tweet with hashtag CircuitPython on Twitter or email to cpnews at Adafruit.com. And of course, as always, thank you to Ann for curating and publishing the newsletter each week. So next up, we will talk about the state of Circuit Python, the libraries in Blinka. Overall, this week we had 68 pull requests merged by 15 authors, which is great to see. A couple of names which were new to me, so these folks are perhaps newer contributors or maybe just less frequent contributors or perhaps even just people who I didn't happen to see before. But a couple of those names are, let's see, Socratesvas, Vladak, RSAH713, Shing 2216, SG Baird, Maxim Kolkin. Maxim Kolkin. Those are the names again of folks that are either newer or less frequent contributors. So thank you to those folks as well as all of our more regular contributors. To go along with those 15 authors, we had 13 reviewers, which is also really great to see. Thank you to all of our reviewers. It does look more or less on first glance to me like those are mostly the usual suspects. So thanks of course to everyone who does review for us. We had, let's see, 68 closed issues by 18 people with 25 issues opened by 17 people. And this is across all of everything, the core and the libraries. But next up, I will pass it over to Dan if you have a moment to tell us more about the core individually. Sure. Thanks. Okay. So in the core we're talking about took a Python firmware itself. Over the past week, there were 19 pull requests merged by seven authors, and there were five reviewers of those pull requests. Right now we have 21 open pull requests. It's a little bit more than usual. Some of them are older. A lot of them are in draft form or awaiting something. So they're not just sort of linger languishing. They're something that has to happen to pull push for some of those forward. We had 13 closed issues by nine people and 13 opened issues by nine people. And there were different issues in different people, at least some of the different people. Right now there are 556 open issues of that. There are no open issues for 7.3.x. There are 39 open issues for 808. I think there were 36 last week. So we've had some more reports of new problems that we might want to fix for 808. We probably won't fix all of these for 808, but this is our optimistic hope to fix those 39. There are 22 open issues for libraries, and there are 494 long-term issues, many of which are enhancements or discussions and the like. And there are three open issues for support that includes the support issues. And there are minus two issues assigned to Milestone. Obviously our goal is to have many negative issues, because what's the opposite of an issue? I'm not sure. Okay. And if you want to look at these stats, you can find them at www.circupython.org. Okay. All right. Thanks, Dan. Next up, I will pass it over to Katny, if you want to tell us about the libraries. Thanks, Tim. So this applies to all of the Adafruit Circuit Python libraries, which is everything that starts with adafruit underscore circuit python underscore, as well as a few extras. So this week, we had 48 pull requests merged, which is excellent, from eight different authors and 10 different reviewers. One of those pull requests was 187 days old, so I'm really glad to see that we're still getting through the older pull requests slowly, but surely. And that leaves us with 23 open pull requests. We had 54 issues closed by 10 people and 11 opened by seven people, so we are net very, very down, leaving us with 637 open issues. 148 of those are good first issues. If you are interested in contributing to Circuit Python on the Python side of things, check out circuitpython.org slash contributing. You'll find all of this information and more, including the list of open pull requests, the list of open issues, and some library infrastructure issues as well. We have a guide on contributing to Circuit Python using Git and GitHub, so don't let that process intimidate you, and we are always available on Discord to help you out. If you're interested in reviewing, you can check out the open pull requests. If you have the hardware, test it. If you don't, take a look at the code, let us know what you think. Leave us a comment, and that is always helpful. And once you're comfortable with that, we can talk about leveling you up to the review team. In terms of library updates in the last seven days, we have two new libraries, TCA8418 and Adafruit Circuit Python GUVXI2C are the two new libraries, and every library was updated multiple times in the last week, so we don't have that massive list in the Nodes document because it was just pages and pages of libraries. And that's what I've got. Excellent. Thank you, Catney. Next up, I will send it over to Maker Melissa to tell us about Blinka. Oh, so Blinka is our Circuit Python compatibility layer for MicroPython, Raspberry Pi, and other single board computers. And this week, we had one pull request merged by one author and one reviewer. There are currently four open pull requests. There was one closed issue by one person and one open by one person, leaving a net of 82 open issues. There were 11,821 PiWheels downloads in the last month, and we are now currently supporting 91 boards. And that's it. Excellent. Thank you, Melissa. Next up, we will start the first of our two round robins, the Hug Reports section. Let me scroll just a bit here. So a reminder to folks, Hug Reports is a chance to highlight folks in the Circuit Python community and beyond for doing awesome things. I'll start, and then we'll go down the list alphabetically and give everyone a chance to participate. If you're text only or missing the meeting, but have Hug Reports in the notes document, then I'll read them off as we get to your turn in the list. So I will kick us off here. This week, I have Hug Reports. Thank you to Liz, who published a guide recently showing how to make an IoT dashboard using the Blinka display, iGame display, which is a mouthful, but a neat library that I worked on. And it's great to see folks making such neat things with it. So thank you to Liz for working on that and publishing it. Thank you to Paul Kuller, who converted a Fusion 360 model file for me over the weekend. Definitely appreciated that. Give me a kickstart on what I was working on. Thank you to Kmatch for providing the Hack Tablets to give away, as well as all the folks who entered to receive the Hack Tablets. Thank you to, or I should say just hard report to, well, and thank you as well, Tektrick and Tammy for joining the Discord Moderators team over on the Discord. And then my last one is a long list, but thank you to all of these folks. Keith the EE, Tektrick, Tammy Makes Things, Paul Kuller, DeShipu, Mark Gambler, and Catney, and anybody else, if I did miss anybody, for coordinating and organizing the Office Hours idea that we discussed in last week's meeting. I think that's a great idea, and we've got a plan moving forward for that. So thank you to all those folks. Next up, we have a 2231 puppy. So I will pass it over to you. All right. So I'd love to give a hug report to Catney for the advice and whether or not to add my board to the Circuit Python repo and a group hug, because Honest is the best tech community that I'm in, and I'm in a lot of tech communities. So that is so great to hear. Thanks. Next up is Dan. Okay. So thanks to Dave Putz, who fixed a couple of Pulsad bugs in the last seven days. That's really appreciated. He's quite an expert on Pulsad right now. Thanks to Jeff Catney and DeShipu for discussing. I sort of had a brainstorming session about an API for disabling and enabling the status bar and proposed some things that we talked about that. That was very helpful to have a sounding board for that. And thanks to TLU, who found a BLE regression in 7XX and did some testing to narrow down what the problem was, and then I made a fix and they tested it, and that was extremely helpful. It all happened really fast, and that's going in, that fix is going into 733. Okay, that's it. Thank you, Dan. Next up is David G, who I will read. David G has hug report for NERDAC and Dan for helping me report reporting a potential issue with CIRCUP, Bluetooth, and the LIWSD03MMC. And then another hug report to Dan again for helping with firmware building on Espressive. And then next up, I will send it over to Jeff. Hello. I want to start off with a group hug and then a hug in advance to Dan, who is going to help me plan and brainstorm when the PyCow stuff gets complicated. I don't know a lot about sockets and SSL, so it feels a little daunting right now. And hugs to Tammy Makes, thanks, and to you, Tim, for working on this new live Discord event that I think you've settled on the name of Office Hours for that. Looking forward to hearing more about how that's going to go. And thanks, Jeff. Next up is Katnie. Thanks, Tim. So, first up from last week, hug to NERDAC for providing me with MD&S Circuit Python code to work with. To Paul Kotler and Keith EE for trying to help me out with Wi-Fi code, though I think I wanted it to do something it can't. And to Dan for troubleshooting deep sleep with me on the Feather ESP32v2. To Todd Bot for putting together send and receive examples using UDP in Circuit Python for me. To Tammy Makes Things and Tectric for joining the community moderators team on Discord. And breaking news to Tammy for joining the Circuit Python librarians review team. As well to Tammy and Tectric again for agreeing to coordinate and host the Circuit Python Office Hours and to everyone who's been involved in the planning discussion, as well as the folks who will be volunteering their time to help out. And a group hug. Excellent. Thank you, Katnie. Next up is Keith EE who is text only. So, I'll read. Let's see. We have Hug Report. I was away last weekend from the end of Circuit Python Day through Tuesday of last week. So, a belated hug to Tectric for organizing the code sprints. And to Tammy Makes Things, the Shippu and Mark Gambler for participating and bouncing ideas off of. Hug Report to Katnie for helping organize Circuit Python Day as well as Paul Kotler for hosting. And Hug Report to Dan H. and everyone involved in all facets of the day. I'm a week late and don't have the sheet of names, but hugs all around. Excellent. So, thank you to Keith for all of those. And then next up is Kmatch. Thanks, Tim. Thanks to you first for organizing and completing the HackTablet giveaways. And thanks to everybody that was interested in the ender. Second, thanks to Fury for some discussions on optimizing the frame rates on the display for the HackTablet. And last, I ran across some good documentation that the Espressive Team has added to the ESP IDF code related to the RGB LCD peripheral. So, thanks for that. Okay. Thanks, everybody. Nice. Thank you, Kmatch. Let's see. Next up, I just wrong tab. There we go. Next up is Maker Melissa. Hello. I wanted to give a hug to Dan H. for reviewing my huge pull requests of new boards on CircuitPython.org and the group hug to everyone else. Excellent. Thank you, Melissa. Next up is Mark Gambler, who is text only likely. I'm thinking, yeah, probably text only. Mark has a group hug for everyone. Next up after that is going to be Paul Cutler. The CircuitPython show turns six months old later this week, so a big group hug to everyone who's listened, guested, and supported the show. That's amazing to hear. Thanks. Next up is Tammy Makes Things. Hey, everybody. So, I have hugs for Tim, Fome Guy for hosting today. To Katnit, Tectric, and everyone else working on the CircuitPython office hours. A hug to Tectric for starting grad school. Congratulations. And a group hug. Thank you, Tammy. And next up, in rounding out, the Hug Report section is Tectric, who is text only, so I'll read. Hug Report for everyone involved in getting the new CircuitPython office hours proposal going. Hug Report to everyone in the community and development team. My first grad course is in microprocessors and embedded systems, something I never would have thought of taking a couple years ago. And lastly, a group hug to everyone. So, thank you, Tectric, for submitting those Hug Reports. And that gets us to the end of the Hug Reports section. So, next up will be the status updates section. Status updates is our time to sync up on what we're doing. I will start, then we'll go through the list alphabetically and give everyone a chance to participate. When I call on you, take a couple of minutes, talk about what you've been doing since the last meeting and what you'll be up to until the next meeting. This is also an opportunity to provide tips and tricks relevant to what people are working on. If a discussion does become too long for status updates, we can always move it down to the in the weeds section that follows. So, I will get us going on status updates. Last week, I did the final selections for the HackTablet giveaway. On Friday evening, that was. I did quite a bit of PR testing and reviews. The one that stood out, that was kind of most interesting. Something that I hadn't worked on as much before was the ELSIM 303 accelerometer. But there were several others in the mix as well last week. The other main thing I got done last week is updating the cookie cutter PR that I put in before. This one adds conditionals to the logic so that the action spot will only print the file size if those conditions are true. There's a couple of different like measurements that it has to surpass in order to leave the comment. Otherwise, it won't comment if it's not a very big change. We can of course customize all those however we want. This week, I am planning to try to finish up the 3D model at least enough to get my first draft print, if you will, of a handheld gaming device that's made from a pie portal and a joy featherwing. Even though it's made for a feather, I'm going to try to stick that joy featherwing down below a pie portal and then have a 3D printed case all around it. Hold everything together. And then the other thing I know for sure that I wanted to try to get in this week is record and publish the next video in the Minecraft feather RP2040 instructions playlist. So I started putting out these videos last week and the one I want to get in this week is the one that will show you how to load code pie onto your feather, as well as initialize the USB serial connection inside of Minecraft and setting up the pins to sync back and forth to the real feather. So that's the video I'd like to try and get out this week. Next up for status updates is 2231 Puppy. All right, so last week I finished up the design work on my digital fidget board, the eFidget, and this week I have to assemble said digital fidget board and test it. That's awesome. Thank you for sharing 2231 Puppy. If you do have a chance, if there's a link or anything, drop the link. I'm definitely a fidgeter. I'm always on the lookout for interesting things to play with.  Okay, thanks. So I'm about to release CircuitPython 733. I just press the button to make the release. And so after it finishes building, you'll be able to see it in CircuitPython.org and there'll be something in the Adafruit blog about it. This has several new and backported fixes that were kind of seemed like they were sufficiently important to get into 733. And some of the few of the fixes are also going to move forward into 800. Otherwise, I'm continuing to fix various bugs for 800. And also, because we're having trouble with Thani right now on when the status bar shows a certain error, it's made it clear that maybe we should have an API for enabling and disabling the status bar, which the status bar can appear in your serial terminal and appear on the title bar there, or it could appear on an attached display. So I've just added some Boolean properties to be able to turn it on and off. And I'm debugging that right now. I should go in pretty soon. Okay, that's it. Thank you, Dan. Next up is David Gee, who I will read. David Gee says, let's see, checking boards that pretend to have a display on CircuitPython.org, trying to find a definition. See in the weeds. It'll be a topic to discuss that a bit more later on. New attempt at doing something useful with my temperature sensor, LyWSD03MMC. Let's see there. Followed the guide on compiling CircuitPython and successfully rebuilt the QDPyUF2. And then we have a couple items related to the Lilligo T-Watch 2020 V3, which is an ESP32 device in the CircuitPython-related world. Installing a expressive SDK, compiling CircuitPython for other ESP32 boards, considering the possibility to port CircuitPython to the watch, checking what components already have a CircuitPython library, and then comparing versions 1, 2, and 3 of the watches for pin usage. There is a link here to a GitHub gist, if anyone is interested in more details on this. In the non CircuitPython side of things, it says, let's see, checking MicroPython firmware availability and trying to compile, checking how to add a board to Whip or Snapper, and compiling and flashing the HackWatch, which is a BLE, Wi-Fi, and IR hacking device. And that one also has a link out to GitHub for that HackWatch, if you're interested. Next up, I will send it over to Jeff to tell us about what he's been up to. All right. Well, I was just typing that making the first wristwatch compatible with Whip or Snapper would be a pretty cool feather in your cap for whoever does that. So I say go for it. But anyway, last week, not CircuitPython, but QMK did one of their feature updates over the weekend. And now there is lots of RP2040 goodness in the easily usable version of QMK. I tried to figure out the mystery of the ESP32 iFlakiness, but I didn't really figure anything out. So I am setting that aside for now as ESP32 S3 is the focus of the camera activity in CircuitPython. And I wrote some new pages for the camera guide on learn.aderfruit.com, but those aren't published yet. Hopefully those will be published this week. This week, also, my work will be to work on the PyCow, the PicoW. I guess I should have listed it in last week. Did I skip that? The PyCow is linking its LED, which means communication with the Wi-Fi part is working to at least some extent. So next up is to make it usable, the LED as a digital IO. And after that, some very simple thing that proves the Wi-Fi chip is actually working for Wi-Fi, such as listing access points or reading the firmware version or just anything that kind of progresses. And just to note, I will be out on Tuesday. Thank you. Nice. Thank you, Jeff. Next up, we will hear from Katny. I have two belated hug reports that I thought of as other people were talking. Thanks to Melissa for finding the ESP32 V2 on CircuitPython.org when the rest of us couldn't. It turns out it's there. We were just not typing the exact string for the title. And belated hug reports to Dan for giving me a build without the CircuitPython status bar enabled of CircuitPython so I could continue working on my project and for working on a way to disable it in code. All right. Last week, I published the ESP32 S3 TFT Feather Guide. Turns out we missed that one in the first sweep when those came out, so that's now done. Picked up the ESP32 V2 Feather and began digging into the various Wi-Fi workflow options intended for a guide on building a Wi-Fi mailbox notifier. Found a bug with CircuitPython and Thani where Thani locks up when an exception is thrown by code. Turned out to be related to the status bar. As I said, Dan provided a CircuitPython build with the status bar disabled. And Thani works as intended again. Spent more time in the Wi-Fi workflow trying to get into a habit with it because the native USB workflow is so ingrained into me at this point. Spent time looking into Wi-Fi data sending options and narrowed it down to MDNS, HTTP or UDP. Sorting out, I sorted out working on two Wi-Fi microcontrollers at the same time using two instances of Thani and also sorted out a way to identify which feather was which. Turns out I was meant to use Adafruit IO for this project and only one feather, so the Wi-Fi data discussions are info for my brain for future projects. I got working code going that sends switch notifications and battery voltage to Adafruit IO from the Feather V2. Tested deep sleep. Got excited because the PPK graph looked like I had deep sleep working until I zoomed in and found out it was still pulling light sleep numbers. Turns out it may be an issue with CircuitPython pulling all pins high when they used to float when going into deep sleep or who knows. Dan's planning on taking a look when he's through his current mission. This week I started on the mailbox notifier guide. There's nothing in it yet but except featured products. I will be assuming the deep sleep issue will be resolved and moving forward with the guide. The main mailbox notifier that will be in the first thing showcased in the guide will be the Wi-Fi version but this all came out of my original Lora version and I will be including the Lora version in the guide as well. So there's going to be two options there. I'm going to redo the existing code from my previous project to work on two feathers because it was a feather and a pie but I'm still going to include the pie code without explanation for folks who have extra pies sitting around already and probably some miscellaneous and that's what I've got. All right thank you Catney. Next up we will hear from Kmatch. Okay thanks Tim. My work continues on the bowling detector slash training aid and last week made some progress. I actually proved that the ultrasonic distance sensors does have a capability for the resolution and speed that I need to capture the distance to fast moving spheres and also demonstrated the position indicator and I'll drop a quick video in the chat. This week I need to make this more cohesive and portable so I'm in the process of designing and need to test out the initial mechanical design. I also need to improve the accuracy some by better smoothing the data and weeding out noise. So that's this week. Thanks. Thanks. Thank you Kmatch. Next up we will hear from maker Melissa. Hello. So last week I submitted a huge PR to add about 15 missing circuit python and blanket boards on circuit python.org as well as going through and upgrading some feature names on blanket boards. I worked on code.circuit python.org mostly I ended up reworking the file dialogue a bit in order to add uploading downloading and file folder renaming. I also added dialogue layering so now over 4,000 dialogues can be stacked up if needed and increasing this number would be trivial but luckily I'll never be more than a few deep in practice. I replaced the each term component with X term so it's now compatible with Firefox. A lot of miscellaneous small bugs and I added a bug fix to circuit python core to add some missing web workflow acceptable cores headers and I started working on adding device discovery. This week I'm going to continue working on that and then I will work on a feature to allow transferring the work when jumping between devices and add more file dialogue features and then update some components that are starting to age from when we originally had it set up for just doing bluetooth. Smooth out the overall flow and just lots of testing and more bug fixes probably and that's it. Excellent thank you Melissa. Next up we will hear from Tammy Makes things. Thanks so last week I worked on the planning for the first circuit python on office hours which we'll talk about in the weeds and on re spinning my circuit python build environment on my macbook because it mysteriously seemed to have stopped working in the last few weeks so I hopefully have that sorted out. This week I'm going to finish getting that working. I'm rearranging my schedule so I have more time for circuit python stuff so I'm going to do some PR reviews and learning how to use the mod functions on discord. I also want to do a little bit of research into audio processing with circuit python because I have a project idea for making a guitar effects pedal for my ukulele that's powered by circuit python and I want to figure out if it's feasible and then non-circuit python related I built a not to scale prototype of a 10-segrity table out of popsicle sticks. I want to refine this design and build another prototype or two to work out some issues and then at some point I'm planning to build a full-sized 10-segrity coffee table with wood structural parts and either steel cables or ropes so that'll be interesting and fun and it's been fun to learn about that so that's what I got. Awesome thanks Timmy yeah that sounds really cool those are always fun things to kind of just look at and ponder a couple of those in my life so that sounds really cool. Next up is Tektrick who's text only so I'll read. Tektrick says last week fixed multiple wi-fi network connectivity issues with the portal-based library removed the LSM-303 library from the bundle I believe that one was replaced by some newer smaller libraries that implement the different sections of that device so this was the older deprecated one being removed added the GUV-X I2C library to the Adafruit bundle let's see made RTD read the docs documentation use a range of years up to the current for the copyright attribution reviewed a lot of type annotation PRs proposed a few cookie cutter and Adabrot patches and updates and then Tektrick has for this week finished up the cookie cutter PR around the Adabot patches proposed once they are approved propose a few more patches needed for the libraries fix up a few new libraries before adding them to the bundle and also starting grad school classes this week. Excellent so thank you to Tektrick and of course congratulations on starting school and that gets us to the end of the status updates section so the final section for today's meeting is in the weeds just a reminder in the weeds is an opportunity for more long form discussions these can either come out of status updates or have been identified ahead of time you do have any in the weeds topics and you have not already added them do please go ahead and drop those in down at the bottom of the note stock that way we don't necessarily have to wait at the end to see if there are more topics and then we will just go down the topics in the order that they do appear in the document and so first up in the weeds topic we have Tammy want to tell us about your topic. Sure so I just wanted to give a little bit more information and a heads up about the circuit python office hours what we're intending for this to be is kind of a space where newcomers can come and ask questions and have some like support and know that there are people there in a kind of friendly and non-intimidating context that can help with questions and getting people started and set up and like that kind of stuff the current plan is that the first office hours is going to be on September 10th and we're tentatively planning from 8 to 10 a.m eastern time although we plan over time to move it around and have some office hours on different times and time zones so that more people can be included and the current plan is that we are going to probably do the office hours on discord and probably the discord video and then record those and upload them to the Adafruit YouTube channel rather than trying to stream on the Adafruit stream so that's the plan and if people are interested in volunteering to be there and answer questions so that we can have more people and cover more time zones and more flexible scheduling please let TechTricker myself know and we'll invite you to join the planning thread I don't think it's private but we definitely want to have as many people as are interested in participating participate. Yeah this is great news thank you Tammy for highlighting that and of course thank you to everyone else who's been involved in coordinating and yeah as mentioned if anybody does want to help get involved by being available during the office hours to help newer folks definitely feel free to join the the thread on discord there let's see here the next one we have let me see lost my place here okay the next item we have in the weeds is for from David and it is at David's text only so I'll read and it boils down to what is or is not a display in circuit python and it's trying to resolve some issues. David's item because we've kind of been talking back and forth in the text document so David asks what is or is not a display in circuit python.org and goes on to list an issue and three PRs that they're trying to resolve so it is a brainstorming question and some of the corner cases are the pu pu 8x8 the pico ed and the mixgo c e all of which have kind of led grid displays something called the df robot beetle which doesn't actually have a display but has a connector for a display and then finally the hub 75 style matrix and this has been a little bit inconsistent up to now and uh David is just trying to bring a little consistency to the to the designation on circuit python.org so I had responded in the document a display is something that uses display i o David asks can you make a one led display i o and I suggested that if you believe it would be useful then feel free to do so I hope you wouldn't do it just to prove a point um and with that I would invite anybody else who has an opinion to just go ahead and chime in well for the hub 75 displays I think we should remove them since they don't actually have the display on the board so for you having the display built in is important and for instance the build of circuit python for the circuit playground that supports the gizmo displays would have display removed because that's yeah it's really a gray area here which is the whole thing because it's like for instance like the beetle it looks like it's specifically meant to be have a display added to it but it doesn't actually have a display itself it just says the connector so maybe it should be removed from that as well so should there be a separate category that's like I think maybe that's where external this meant to be used with an external display you know so well hub 75 hub 75 refers to the connector on on some of the led matrices yes isn't it yeah that's a display it's just not attached it's actually a display it's not a it's not a uh device right and we just we don't want to have like 30 different features either we want to keep kind of keep it limited on the list so that's the other side of this would it make sense if you create a monster you wind up creating a monster selection list hmm a select uh combo box would it make sense if the future name was display i o instead of displays more generally and then the cutoff point is the ones that support display i o which would cover the gizmo seem to have lost sound we're still here charles yeah so I think I would say like yeah you want to say like I mean I think it's good to know which ones have an on-board display and you could even say like on-board display or something like that and you could or in the other ones could say off-board display support or something like that external display support yeah so I think both those both those things are interesting uh although almost anything with stemma qt and which isn't so constrained that it has display i o configured out would count as that well I I'm thinking about specific display hardware yeah but in which case so there's has a display and there's designed for a display yeah that's exactly the phrasing I was thinking of yeah exactly yeah okay or meant for use with an external display that's kind of wordy but like display included or intended for use with external display yeah yeah less wordy than that yeah something like that right so well then that leaves non display items like the pu pu 8 by 8 which I don't think uses display i o would that I would call those things a display exactly because that's how they're used yeah you know and yeah cadney's led display that's an option yeah it depends how many properties we want or you know how many additional features we want to add to the list which I think adding one is okay probably I think just saying that there's I right I think I think whether or not it's display i o I think that's less important than the fact that the board board has an on there's an on board display or it's meant to be used with a display and those are the two sort of the two categories not can be used with a display that's sort of true of every board but right yeah so yeah they would probably be on board display then yeah designed for use with an external display yeah so something like that yeah so yes this is not cut and dry it's just gonna kind of be like we have to use our judgment on it uh David if you feel like you understood what we discussed and if you don't um disagree too sharply can you write that on the issue and then work on those prs accordingly all right yeah thank you that's that's really appreciated um because yeah it is it is always going to be a little bit hand wavy or a judgment call as melissa points out but asking us to make that judgment call rather than let it go is also important so thank you and now assuming for me guys mic is working again I'll step back out of the way yep I think we are good here uh just check in the folks can hear me yep okay um yeah thank you Jeff for handling that section in the weeds there um that gets us to the end we have no other in the weeds topics for this week so we'll have the wrap up next I will take the last time stamp so next meeting is one of the relatively rare runs where we are actually going to be bumping a day forward so the next meeting is on Tuesday September 6th 2022 that is 24 hours later than normal so it will still be at 2 p.m eastern 11 a.m pacific but it will be on Tuesday September 6th uh the Monday before that the fifth is a us holiday so we will be one day later than normal for the next meeting uh so with that I will say thank you to everyone for participating and we will see you next week on Tuesday thanks everyone thanks everyone


Welcome to DefCon 2022. I'm a moderator for this session. My name is Andrey Veselov, and me and Richard Philo are moderating this. This session is live, and there will be a time for your questions. Use the Q&A section, please. And from this moment, I'm giving one to presenter and see you soon. All right. Thanks, everybody. I'm David Duncan. I'm a principal partner solutions architect at Amazon. And my role as a partner solutions architect is to work with our open source platform partners. And I spend a lot of time working on Red Hat in my day job, and then in my volunteer time, and whenever I have opportunity, I work on CentOS and Fedora projects, including the Cloud Six. So we're gonna talk a little bit today about Amazon Game Day and the event engine and how this all comes together to make a gaming experience. And one of the things that is exciting to me is that Game Day was created in the context of the partner team almost from the very beginning. We had a small group of partner solutions architects who were involved in, actually they were just called solutions architects at that point. The Obama for America ops team. And if you don't know, that was Ryan Nall on top of Amazon Web Services and was a super exciting experience. But Amazon.com had what they called a Game Day. And Game Day was this operational stress testing and validations that they did for new hardware or new system setups. And that continues today. That's a part of the sort of the culture of the Amazon experiences. Is there is what they call a Game Day for pretty much anything that is new or has not yet been tested by customers where they just hammer it. But we created a Game Day out of that. And there was some really amazing people. Scott Ward and David Rockamora are two of the people who originally worked on Game Day and just amazing engineers who happen to be part of the partner solution team. And the way Game Day works is we break up into teams of four and or break people up into teams of four. Usually there's a lot of people who are playing the game. And the tenant is that there is no right answer that absolutely there's no way for you to be wrong outside of just not having enough points to win the game. And it's a hands-on experience. Everybody gets to touch keyboard. You get to look at problems, try to solve issues. Some of them code, some of them just operational and determine how you can do that. And the goal is to build communities around the technology, right? It's a really easy way to do that because this is a time when you are put in these groups of usually randomly assigned, right? We try to break as a rule, the goal of the game is to break up groups of people who really know what they're doing and put them with people who really don't or maybe don't have a significant significant amount of experience around a platform. So then you'd have some people who are senior developers but have never touched Amazon and then other people who are maybe junior developers but have a tremendous amount of experience and then all ranges, right? So every functional ability and role from business development managers to product managers, to seasoned developers, seasoned DevOps groups or individuals, so it's flexible. And one of the things that I really love about Game Day is that you have this opportunity to build in whatever can run on top of Amazon infrastructure which includes lots of partner solutions and we'll get into that a little bit later. That's a duplicate. So this is what a Game Day looks like. This is three people from the Game Day advisors they're walking around making sure that everybody who has questions gets their questions answered or if they're looking for hints in as to whether or not they're on the right track. These are the guys who are standing around talking to them and this gentleman in the red shirt is a participant who is asking a question and this is a group of partner development or partner solutions architects who are answering his questions. Now, we've done this in the past where we had some Ansible modules and those Ansible modules fell out of support for the program and this could and has been Red Hat engineers but it could be CentOS engineers or it could be Fedora engineers who wanted to be to participate in building and supporting this type of environment and work. And so here they all are working away in these big teams most of them probably may not have ever seen each other before in their lives, right? And this is why I think this is something that I want our community to participate in the game day. Everyone who is part of this experience comes out of it feeling better than they did before, right? And they're upskilled on related technology. So when we know that people who are having a great experience getting a little trophy with a unicorn on top of it and by the way, these are probably just horse trophies where they taped or glued a toothpick to the front of the horse. That's typically how we do that. Look at the statistic, it says 92% of the people who do this want to do it again, right? And I think that speaks for itself.  And this thing can happen anywhere. This happens to be in Austin, the one before this that I was showing that happened to be in Las Vegas. These are, this can be a very large event. And people, when they talk about it, they say that it was the most amazing thing that they've ever experienced, right? They helped me feel more comfortable using the console. I want to do this again, right? Is one of the things I love. And the framing device of stepping into a startup to clean up someone else's mess is an entertaining and realistic experience, right? So the way it works is it takes about 30 days for us to set up the infrastructure environment, make sure that we have everything together, that there's no conflicts with any of the other events. And then the setup, basically the event is set up and then once game time arrives, everybody gets to participate. But that's not why we're here. We're here because we want to know how this thing works and how we can participate. So the linchpin of everything is what we call the AWS event engine. And the AWS event engine is a sort of a living space and code base in an Amazon account that provides the framework for all of the things that go on, that these participants interact with. It creates an account structure for each one of the individual participants. So one of the, or not participants, but each one of the individual teams. So each team of each group has an isolated account structure that doesn't have anything to do with anyone else's accounts in the room, right? So we've separated everything out. And then the engine itself will create that kind of a configuration in a way to support game day or now we can support workshops. With that same functionality. So if a group wants to do an immersion, they end up using this as a way to isolate infrastructure and make a sandbox. And then at the end of the day, they clean up the entire event engine. The event engine has the event, right? Has a finite life. And when you close it down, all of the resources are destroyed. A little bit like deleting your account at the end of the day. So stay tuned to this space where all of the workshops that are being created now, they are being done in this 2.0 version. So all of the things that I'm saying are probably going to evolve. I mean, for every system here, there's a next generation and this is it. This is what it looks like. But this one provides a source forage support and makes it possible for us to have publicly available accessible content for the whole AWS experience. And that's something I'm super excited about and why we're here today. This will be more publicly accessible. So an event engine creates for any event an AWS organization and an AWS. So Amazon has account structures for web services. And in that account structure, there is a single account, a single account for an event that is called the central account. The central account has access to all of the team accounts. Each one of the individual team accounts has resources. The central account through cross-account access is able to manage and make modifications to the team resources. And that makes for some fun antics during the game. So there are obviously there's development, but then from the perspective of the game itself, the operator is king, right? Somebody has to go in and set up an event and start all of the work. So an operator is a role where someone sets up a blueprint, they look at what it is that they're playing to do with the teams. There's some very specific information that's associated so that we know what kind of resource limitations to put on each one of the accounts that's created. And then the user gets a little dashboard of their own and once this event is started, right? Once the operator goes back and says, okay, I wanna start this game, then the user, the team gets a dashboard that they have access to that provides them with console access for their temporary account and then credentials for logging into the instances that are pre-created, pre-installed. And the system. So now those users, those participants are participating in the event, right? So there are lots of different types of events. I've put down some suggestions here for the types of events that we might have in the future. And then I've shown that this is made up of modules. So I've also put down maybe some modules that exist and some that maybe should exist. So let's say we had created a module for the Open Data Hub Machine Learning with a game, with some sort of a game angle to it. And we added that to a game day blueprint. The blueprint would then be made up of a group of these modules. Once that blueprint is created, the blueprint sort of aggregates all of these component parts together. And we can assign that blueprint to one or more events. So from the back end, we're able to take the modules and the modules are really what it is that we're focused on just to let you know for the deep dive on code and create the blueprint. The blueprint then can be used in it's, in whatever state it's in, in a specific event. And you can have multiple blueprints that are associated with a single event, meaning that if you've got specific versions of specific pieces that work well together, then you can maintain those together and you can maintain them, maintain the groups of blueprints so that you can use them to create larger or smaller games. So looking back at the team and the components, when we create, when we create a team, it's usually one person for a workshop. You know, the size is usually one person for a workshop but for four people ideally for a game day. And a module has the ability to, well, a module provides a CloudFormation template, we call it the central template. And it's the central account that issues that and generates the, generates a team's resources. A team has an IAM policy and that IAM policy is used to generate roles for the actions that resources can take. And then those resources and the functionality of those resources contributes to your score. So blueprint has, so blueprint for a module would have a read me file for the operator instructions, a team role for IAM policy, pre provisioned infrastructure, which is in the central template. And this is where I'd love for us to be able to create resources like OpenShift Clusters or even rail configurations for different tools, possibly, you know, control hubs for Ansible configurations could all be a part of that. And it's where we have interactive experiences like creating outputs, inputs, stuff like that. Then there are what we call checkpoints in scoring and I'll go into this in detail in support for remote events. So let's start by looking at the read me. Read me's are usually just marked down, super simple configuration. So we create it, we give an overview of what goes on in the module and we talk about exactly what happens in this, you know, in this lab, you know, we're gonna be doing such and such a thing. And then we have more detail and then there's a quality checklist which kind of identifies exactly what's going to go on in the module and how you will understand, how you'll know that it's fully functional. And then there is, you know, there are guides, guidelines for building and developing these workshops. So the policy module is a really big deal. This is kind of the first and the first actionable thing, right? If you have any resources, there has to be a policy that goes with them. And this is, if you're looking at the policy, this is an IAM policy or module policy. I'm sorry, that's backwards on the diagram. So the module IAM policy in this case is one that's very relaxed for S3. Obviously, this is a configuration that's pretty easy. And you can set up, so the thing that makes this great and the thing that makes this easy to do from the outside, right, as someone who wants to participate in the game day experience is that there are these variables that are used in our configurations so that if you have a module policy, module policy can be set up in one account and run in one account and there's a mock environment that we can use to get the experience of doing this as if it was in the event engine. But then we can replace a lot of these things in the CloudFormation template, account information, region information, region specifics, role names, et cetera, with these variables. And then those can be the event engine itself can transform those variables into the content that they need to be. So if you have multiple modules, you have multiple module policies and those IAM policies are aggregated through the event engine. So we consume these modules here into an event. That event is managed and deployed by the event engine and the event engine takes all of these policies, combines them together to create one, well, it doesn't technically combine them together but it applies them and they all have, they all are associated with the team and the team's resources. And basically that gives the access control that a team has inside of the account. And the same thing happens for building those resources. So the collected resources that are built using the central template. And this is a, I showed the policy in JSON but this is a CloudFormation template in YAML. When you look at the configuration of the CloudFormation template, it's setting, this is setting up the parameters for the variable, or for the variable parameters for the template. And the parameters for the template are filled with the variables that are part of the configuration of the game day. So a lot of that is determined by the engine. So the things that are set up in the event determine the values of the event, like the event ID, the generated team IDs. You have to tell it how many teams you want to associate assets bucket for the event. So any assets that are leveraged by a module, they would have to be available through the central account. And so there we usually be a central account, or in a policy to make that central account access work. But all of this again, can be done in the context of a single account structure. And the goal here is to set up all of the, to have all of the resources that are necessary for the game to work preset for at the time that the game starts. And that way people can come in, we set the game up, they enter their IDs and that identifier gets them into the game and off to the races with the resources that are built here. And those resources could be OpenShift Cluster, they could be OKD, they could be Fedora Cloud instances, they could be an entire configuration, an entire solution from whatever open source experience that we wanted to bring to it. And the interact, so don't just stop there, each one of these modules, we have the ability to create these kind of behind the scenes, interactive moments inside of the game. And that can be something as simple as determining a way to pre-populate an necessary bucket in a central account. So suddenly during the game, a necessary bucket has different information than it had before. And if they're, this can be used to kind of level set whether or not they're doing proper ingestion from the location or if there's a trigger or something like that, we can make all of those things happen. And this could be, again, part of any sort of centralized part or solution component of anything we can do in Fedora, Fedora solutions, anything we can do with CentOS as a base, anything we can do with Red Hat as a base. All those are available and something that we could deliver and get an experience where people are learning to use it and getting comfortable using it in this context where they don't have anything to lose. And this interactivity makes it a sort of a living experience. And that kind of comes, falls directly into the next part of this, which is the score. So scoring is really one of the biggest and most important things that you do. And the checkpoint, just to keep this conversation going around the checkpoints, we set those up and make sure that if things are going properly, if at this point we can determine that one of the players or the team has set this up right, we can award some big points. Now, that's a great way to go, but then points and scoring can't just be a one-time thing, right? Can't just be suddenly it came out of the air. Scoring has to come from somewhere all the time. And this is kind of a blurry picture. I'm sorry, I even, I literally cropped this out of one of the pictures from earlier. But what you're looking at there is a list of teams and their scores and those scores are going up and down based on what they've done. And that scoring process is an iteration. It's a Lambda function that goes out and retrieves a list of all the teams and iterates through them. And checks if the team has reached whatever checkpoint it is. And then if the checkpoint's set, it will dispense the points. And the same thing happens for other sort of scoring models. So we can have functions where if a system is responding, as it's supposed to. So let's say we set up a microservice for a customer, in the game we're setting a microservice up for our customers. And there's a way to have the other teams be your customers. So you have a system that is a customer, you have a system that is both a customer of all the other teams and is a provider for all the other teams. There can be a scoring mechanism that is part of the successful completion of a share or the failure of a share. And that's those kinds of adaptive models for scoring are super helpful and very easy to implement in the context of the game. So we have lots of scripts that can be just added in to make that scoring work. If it's not clear what I'm saying, it's I'm kind of alluding to the fact that you could create a simple service that would both send and receive from others of its type and provide a way of making that work and making it score. But then also we can add interactivity and adding that interactivity means setting up a service that will at some point in the life cycle make a change to the system that they're using, right? So we might break the security group rules and then they have an operational problem instead of taking on the functionality of the microservice. The microservice is fine, but something we can deliver a different challenge over time that might cause them to lose points in a way that they did not expect. Okay, so now I feel like we have a pretty good understanding of what it is that we're looking at. We've got three things that I think are really important. One is we have the central template. The central template creates the content or the resources. And the central template is run in the team account to generate that, to pre-populate what it is that the team members will interact with. And that's done with the central template. And that's done in a CloudFormation template, along with a group of scripts. So part of what happens here is resources are established, an S3 bucket is created, that S3 bucket can then include things that happen on those resources that are created or serverless functions or configurations for services. And that can function just the same way in inside of OpenShift as it can on some bespoke pre-existing service. So now I have some gratuitous use of colored slides and this is my call to action. I don't have, there are no Fedora, CentOS, or Red Hat OpenShift based game modules. And so I think that this is a deficit. I really think it would be super fun to know that there were people out there in the world who are getting as just as excited about the community experience as I am and just as excited about being able to work with OpenShift and container-based technologies that we've grown to love over these past few years as much as I do. There ought to be a SIG. And I think that that's really something that we don't have right now that we really should is I think we should be working on some really fun ways for our new users and old users alike to gain insight into the technology that they are interested in and especially the technology that we're building. And then just I wanted to end with a look at what kinds of things, what kinds of events and blueprints are being created and the target groups that are there. And we can take these same kinds of paradigms and build our own event configurations and find ways to engage groups based on that. So we have these blueprints, each one of these blueprints kind of fits to a group, an audience and a duration. There's almost none of these experiences that go less than fewer than four hours. But this basically tells you a little bit about how each one of these game modules works and what it is that they're targeting for the users. And you can see that everybody's getting a lot of introduction to very specific services in this case and very specific content. And some of these are super simple, right? They can be as simple as just I have a website and on that website, if it's working correctly, it will reverse the word that I send to it. And some can be as challenging as trying to determine the specific security vulnerability that is being exploited. This will be a fantastic compliment to OpenSCAP and this is probably the shortest one. I was looking at energy focus. And then I'll end here. But this is some real world discussions. There's a series of YouTube videos out there to show some of the strategy. So there's one where two solutions architects are playing the game and they're actually going through. It's actually a Twitch stream that's been captured. And then there's another really good sort of breakdown of the financial services game day that I think is amazing. And then the last link is just the link to the game day itself. So thanks everyone for paying attention and being a part of this. Super excited about this. And I will say we can take questions now. So Neil asks, what do you think would be some good first modules? I think some really great first modules would just be building out some functionality on top of simple components. And maybe having scaling issues. So finding a way to set something up so that you need to respond faster than one, faster than a constrained pod can provide and then have the team have to figure out what to do. And effectively any basic best practice is gonna be where I would like to go with that. And then let's see, a SIG for building conference games for these technologies and Fedora sounds like an interesting cross between mind share and technical governance. I have, and that's part of what I'm doing here, Neil, is I really think that I'm kind of trying to gauge the interest and generate a little bit more community drive. But yeah, I think it should be more formal. Mark, so how does the scoring work? So scoring works two ways. One is you can have a scoring service touched by whatever it is that you're doing.  Let's say you have an application that has a reverser in it, right? So I'm running a web, a web application with a reverser. If the reverser doesn't work or if the web service doesn't respond, I can say, okay, well minus five points for, I didn't get there, minus five points for, it didn't reverse my word. Or I can say plus five, I got there. And then plus five, it reversed my word. And that works behind the scenes for us, that works with CloudWatch and we can typically, we typically have a communications agent through the event engine that will go back and filter through all of those scoring modules. And then the other one is the checkpoint. And the checkpoint is also hidden inside of the event engine, but it's basically you say, you identify a specific condition. And usually that's a CloudWatch metric or some sort of something that you can, you can poll or whatever to determine that you've got a successful run. And that can be, that can be done through an interactive experience too. So a customer might be, they might input a hash that was generated from a service that they, that was broken and they had to fix. So it can be interactive from the, with one of the team members inserting it into an input field on a web form or it could be a Reaper that just goes out and determines whether or not the functionality is correct. And each one of those is considered to be what we call a checkpoint. And then there's the interactive scoring. Yeah, so yeah, the OpenScap I think is like, that's one of the ones that I feel like we have a really easy way of putting it together and having people understand best practices around it. One of the scenarios that I can imagine almost immediately there is a customer who is getting a report that their extended update support service version of Red Hat was out of compliance because they were using the wrong SCAP feed, right? Or, you know, same thing, something similar, excellent. Well, I'm glad I could be of service there, right? It's a great, it's been a fabulous friend to me for a lot of time, fighting back people who don't understand the Red Hat and the RPM packaging model for handling security updates. Any other questions? And if there was a repository out there that you could participate in and a testing model, a testing framework that you could participate in, that fit into the model, do you think any of you might have interest? Yeah, yeah, I think that that's a reasonable answer, Neil. I mean, it is a lot more, I think it would be more fun to, I think the fun comes in finding out that you've got something that is super simple and then putting a scoring model to it. Yeah, I think that having the scoring modules and being able to see that you're getting 100 points or five points or whatever for the experience is probably great. And then I meant to run a game day here, but we couldn't negotiate the short amount of time from acceptance all to completion. But I would like to do that. I'll definitely gonna try and get one set up for, I've already, in fact, got it established and ready for Summit and also for devconf.us. For devconf.us. And if it's accepted, then I would love for us to all participate in this game. But I'm gonna ask for a little bit of a commitment. I wanna do at least two hours in the workshop so that we can all get some big points and we can watch somebody walk away with a nice unicorn trophy. That's right, horse with a toothpick. Mark, I've had really positive experiences with the virtual game days. So you can still, that's true, they were pre-COVID times. So the way we do a remote, I didn't actually put this in the slides and I should have, the way we do a remote one is we have, we use the Amazon Chime as the basis and Amazon Chime has a web client that works. Well, with Linux, but there is also a Pigeon plug-in that was made by David Woodhouse that works really well for just basic connectivity. But teams have their own, they basically have just a conference call together like a conference call together and they work through the problems. And that gives you chat and a lot of times chat is even better. What we found over the years is that the people who participate don't necessarily come from the same place. So some people who speak, if the game's in English, a lot of people have English as a second language. So the remote experience turns out to be better for the people who have an English as a second language experience because it's easier to part, it's obviously easier, I think for all of us in our second language to write than it is to recognize the idioms of native speakers. And so the experience is really super positive especially for people who might not have been as included in an onsite experience. So we found that that works out pretty well. The people that I think have the best time are the people who just sit down and enjoy learning. And one of the things that I thought was the biggest success in running a game day was seeing a group where about four of the tables had just abandoned the game but they were all squirreled around one person who really understood what was going on and he was just basically giving lessons, right? And he was teaching everyone about access controls and security configurations and just going through each one of the things that he was doing. And most of the people had just stopped playing the game but they were having a blast just watch it, just standing behind him. And then obviously an entirely different group won the game day but it was, but I felt like the experience that they had where they spent so much time learning was just as good if not better than winning. Anything else? Anyone else? Yeah, the teams are, so we try to make the teams random mark. That doesn't always work out because some people are adamant about sitting together, being part of the same team and there's no reason to stop that, right? I mean, this is not high stakes. We're talking about people who are getting their names taped to a statue, right? We're not talking about, this would not make sense as a high stakes experience, right? This is a learning experience, a hands-on immersive educational experience, not a tournament. Awesome. Yeah, thanks for being here and thanks for participating. Thanks, Radek. And I can tell you right now that part of my world will be making this happen. So I'm super happy to be a point of contact and someone to help you get through all of the detail that's necessary for you to participate successfully. And I really appreciate everybody. I'll leave it there. I think we're at the top of the talk. Thank you, David. Thank you. Thanks to the speaker and thanks to the audience. It was a great presentation. It seems like we finished a bit sooner and it's good. So the next session will be in nine minutes and I think see you soon on the next session.