about making authentic and simple videos and just want to tell you a little bit about it so first of all why is it important to make videos now you probably have heard other people say well it's a really great marketing medium to connect with your potential clients and of course I completely agree with that just about all of my clients told me that they watched my videos before the deciding to work with me meaning my videos were an important part of their decision to see whether or not I was going to be the right coach for them so yes making videos is a very impactful way to connect with potential clients and to really see if your energy signature is a good match for theirs there's no better way except through in person of course if you can be with someone in person that's great but besides in person video is the way to test out your energy signature with somebody else and with video you are doing that kind of testing with thousands or millions of people at the same time and so basically your ideal clients and your kindred spirits will naturally find their way to you through that energy signature match through video so yes video of course is an awesome channel for connecting with potential clients but let me spend the we're back here there was a little bit of an internet issue so I'm going to tell you about something most people don't say about videos video is actually a remarkable tool for building self-confidence and authentic expression and finding your calling why is that let me explain is there a more authentic way to communicate online except through video especially live video no there isn't right because you could of course write things you can write articles you could be authentic and you're writing but writing of course there's lots of editing involved usually you could of course make pre-recorded videos and do a lot of editing but with all that editing it's not really your authentic presence anymore sure your authentic style might be in there but live video well it's like being in person with someone and being able to share from the heart in real time with your real expressions without editing right so when you practice sharing from the heart a message that's meaningful for you you are using your real voice your real voice when you share meaningful experiences and do it in a live format you're sharing your that's an opportunity to share your heart right and when you practice doing that again and again and again it's it's just the most remarkable way of building your self-confidence because you realize wait a second I am able to speak my truth and to do it in public right and not only that people at least a few people seem to be connecting with that because they watch the video maybe they even liked it if you're you know as you build a bigger audience you'll get more likes and comments but in the beginning don't worry about that just the fact that someone watched your video means that they took the time to watch it means that they resonate in some way with your authentic presence so the consistency of showing up on live video is one of it's my favorite way of building self-confidence I recommend that to you highly and I also said that video doing authentic simple videos is also a great tool for finding your calling why is that because what is your calling what is your purpose in life now let's not go into the bigger purpose like for all of life but let's just say your your career purpose the purpose in for your work your business what you're meant and called to do in your work is the intersection between your authentic expression and what the market wants from you that's your calling the intersection between your authentic expression and what the market wants from you and through live video you get to be practicing your authentic expression again and again and again and then noticing with the metrics which of your live videos have got the most market response and the more you study that intersection the more you discover your calling meaning oh wow people really find it impactful when I talk about this particular aspect of my life experience or talk about this particular topic and talk about in this particular way wow or you also know that when I talk about this topic it doesn't resonate as much with people or when I talk about this my experience in this way it doesn't resonate as much but this way and this topic really resonates with people let me do more of that because that is your calling so if this sounds important for you as an experience to have I encourage you to check out my upcoming course it's called authentic video creation and we talk about mostly about making live videos and doing it on a consistent basis and how do you show up naturally and confidently on camera we'll talk we'll do many exercises to help you show up in that way and also the students of the course will have a private facebook group where you get to experiment on video whether it's live video or pre-recorded you'll share your videos as many as you want into this private facebook group and get some mutual support there with other students so if this sounds interesting go check out it's on my website and go under workshops and it's authentic video creation as of when I'm making this I'm going to be teaching it live soon but even if you watch this video years later the the course will be available for you to watch as a pre-recorded and the faith the private facebook group will still be available for you to experiment and get some mutual support and feedback also when you join the course you get access to live group Q&A calls with me whenever you buy this into the future you'll still get two live Q&A's with me where you can come and get my feedback if you want on how you're making your videos so I hope this is inspiring for you or interesting and perhaps I'll see you in the course thanks so much for joining me


What's up everybody, JZ here for Jatsby's casebricks.com. 2022, National Treasures, Picatinny number 14 baseball, just sold out with this random number block. For these 10 teams here, guys, Red Sox, Dodgers, White Sox, Tigers, Nationals, Phillies, Marlins, A's, Rockies, and Brewers, get a piece of these teams via a serial number break, random number block style. Again, we go by the first number on the left side of serial number dash, there's our examples there. Remember, any non-numbered cards are randomized to the group. And here we go, guys. So here's the dice roll, here's a customer name, it's from John, down to Jeremy. That is the number zero, one, two, three, four, five, six, 79, let's click dice roll. And that's a four to five, nine times, good luck. One, two, three, four, five, six, seven, eight, nine. Nine times, four to five, nine. Alexander, down to Jeremy. Nine times, four, five, nine. One, two, three, four, five, six, seven, eight, nine. Nine times, nine times, one, down to nine. All right, down to a one, John with two, Jeremy with six, last but not the only Joe. Ed with three, Jack, any non-redemptions, John with eight, Rick with four, Jack with seven, Kev with five, and then Jeremy with nine. So in a separate video, we'll start the break. Good luck, everybody.


Most of the ebay dropshippers are working only with products between $5 and $50 and they miss the most profitable niche in any ebay dropshipping business and in any ebay store which is the expensive products, the products which are over $100 and even products which are over $1000. There are two reasons why people don't work with these expensive products. The first reason is because it is dangerous. People know that this is dangerous and they are right. And about this I will talk on the video which I will release tomorrow. So if you are watching this video more than one day after this video released, you can take a look on the second video also. The thing which I will talk about with you on this video is the second reason. The second reason is lack of knowledge. People don't know how important it is to work with expensive products and how profitable it can be. So let's take a look about six things why you must start working with expensive products right now and why this will increase your store profitability by a lot of percentage. I am Lior Pozin. I am owner and CEO of PhotoDS. I am doing dropshipping for over 10 years and today I will talk with you about six reasons why you must start working with expensive products right now. So the first reason is this that expensive products cost you much less fees because of their high profitability. So let me explain you what I mean. So let's go and check this sheets file. So if we have 1000 products in our store, it means that we have the premium subscription store. It means that we pay to eBay 60 dollars and if we have in PhotoDS 1000 products we will pay another 40 dollars to PhotoDS. Which means that for 1000 products we will pay 100 dollars fees. This means that our break event starts from 100 dollars if we make less than 100 dollars per month we will lose money. So what does it mean? It means that every product which we upload cost us 10 cents for 1000 products. If we have 10000 products it will cost us 0.06 cents per product. So what does it mean? It means that if we sell products in average of 25 dollars per product with 7 percent profit and for each product we will make on this way 1.75 dollars profit. It means that we will need to cover our fees which are 100 dollars. We need to sell 58 products per month. So let's calculate it again. If I do 100 products divide to 1.75 we will get 58 products per month which is around 2 products per day. What about if we have some products which cost 200 dollars with the same profit of 7 percent? We need only 6 orders of products like this per month to cover our fees. What about products which cost 1000.5 dollars which we sell with only 3 percent of profit? We need only 2 orders like this to cover our fees. Now I don't say that you can't sell products like this every day but selling one product like this in a month will cover half of your fees which is amazing. So when we sell expensive products we can make much more profit per product and we can make much more money and cover our fees much easier. So this is the first reason why you must start working with expensive products right now. The second reason is payable fees. When we sell a cheap product for like 5 dollars the percentage of the payable fees is very high because we pay to payable percentage plus we pay them 30 cents per order. So this 30 cents is very high percent of an order of 5 dollars. So this is the second reason. The third reason is the customer support. When we sell expensive products we need to spend much less time for customer service because every product gives us much more profit so we can afford it ourselves and we also sell less products but with more profits which is amazing for us because for each product we give less customer support. On the next video we will also talk about how to give the best and the right customer support with expensive products without staying on the dangerous side. The fourth thing is that expensive products have much less competition. Think about this. You are not the only one who is afraid to work with expensive products. Most of the dropshippers are afraid to work with expensive products and this is why there is much less competition for these products. The fifth thing is that for this product it worth it to do the optimizations. So if we spend time for a product and we optimize the title, diet and specifics, the images, the description so it better to do it for a product which will bring us much more profits and not for a product which costs us which brings us only 1 or 2 dollars profit.  The next thing is that these products you can keep them in your store even half year or one year and it doesn't matter because one sale of this product can cover you like ears of fees for these products. So it worth it to keep these products in your store even for longer time period because these products are the main profit of your store. Now one question which I want to answer here is which percentage of our store should be expensive products. So I recommend around 20 or 25% of your store to be expensive products which are over 100 dollars. Be aware, this is dangerous and you must know how to work with these products in the smart way and in the safe way about this we will talk on the video which I will release tomorrow. So I hope that you like this video, write down in the comments if you are working with expensive products right now and if you plan to start working with expensive products right now and don't forget to subscribe to our YouTube channel for daily videos. See you on the next videos, bye bye.


Hello, everyone. This is the Circuit Python Weekly Meeting for June 12, 2023. It's the time of week that we get together to talk about all things Circuit Python. I'm Jebler, and I'm sponsored by Adafruit to work on Circuit Python, which is a version of Python designed to run on tiny computers called microcontrollers. Circuit Python development is primarily sponsored by Adafruit, so if you want to support Adafruit and Circuit Python, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join any time by going to adafru.it-discord. We hold the meeting in the Circuit Python DevText Channel and the Circuit Python Voice Channel. This meeting typically happens on Mondays at 2 p.m. Eastern, 11 a.m. Pacific, except when it coincides with a U.S. holiday. In the Note Stock, there's a link to a calendar to view online or add to your favorite calendar app. We also send notifications about upcoming meetings via Discord. To receive those notifications, ask an admin or community moderator to add you to the Circuit Python East's Discord role. There is a notes document to accompany the meeting and recording, and the final notes document will have time stamps to go along with it so that you can skip to the parts of the meeting that you are most interested in. After each meeting, we post a link for the next meeting's notes to the Circuit Python Dev Channel in the Adafruit Discord. Check the pinned messages icon in the upper right corner of the screen to find the latest Note Stock so you can add your notes for the following meeting. And if you wish to participate but can't attend, just a reminder, you can leave your hug reports and status updates in the document for us to read during the meeting. This meeting is held in five parts. Next up is community news. A look at all things Circuit Python and Python on hardware in the community. And it's a preview of our Python on microcontroller newsletter compiled by our own Anne B. Thank you, Anne. Then we have the state of Circuit Python, the libraries and Blinka, where we look at the numbers that tell us the health of the entire project, separate from what we're up to in kind of a narrative fashion. The third part, and when you all get to start participating, is called hug reports. Hug reports is an opportunity to highlight the good things folks are doing and to take the time to recognize the awesome folks in our community. The fourth part is status updates. It's really the meat of the meeting, an opportunity to report on what you've been up to. We invite everybody to take a couple of minutes to talk about what you've been doing since the last time you dropped in and what you hope to get up to over the next week or whatever time frame is relevant to you. And the fifth and optional part is in the weeds. If we need a more long-term discussion, that is where it happens. So we'll take those in the order that they are in the notes document when we get there, and that covers how the meeting will go and now a preview of the Circuit Python and Python on hardware newsletter called Community News. Number one, Circuit Python 8.2.0 Beta 1 has been released. It is a beta, so we invite folks to try it out and let us know about any problems. There are links to the Adafruit blog as well as the release notes on GitHub, and thank you, Tim, for getting those links into the Discord channel. So the highlights are continued enhancements of Synthio, the addition of alarm.sleep memory on the RP2040, and reduced size of stack frames, which sounds a little technical, but it will help on some of our lower capacity devices. Next item is Focus on Risk 5. A major tectonic shift away from arm to risk may be in the works for Qualcomm, Samsung, Google, NVIDIA, and Apple, says an article at Patently Apple. You can get started with Risk 5 quickly without using an FPGA or Logic Simulator with the RV32i Risk 5 Simulator, which can run MicroPython 1.19, and analyze the emulator to understand Risk 5, and there are some links to Twitter and GitHub.  Ardan Labs talks Adafruit Engineering and Forest Service, with Anne Borrella. They spoke on a number of topics, and there is a link to the YouTube broadcast. So if you want to learn a little bit more about Anne, she's a very colorful character, check that out. The CircuitPython Weekly newsletter is a community-run newsletter emailed every Tuesday. The complete archives are at AdafruitDaily.com slash Category slash CircuitPython, and it highlights the latest Python on hardware-related news from around the web, including CircuitPython, Python, and MicroPython. To contribute your own news or project, edit next week's draft on GitHub and submit a poll request. There are links in the notes document. You can also tag a tweet with hashtag CircuitPython on Twitter, or email cpnews at Adafruit.com. And yeah, we love hearing about your projects. We love just anything, any news item. Please hit us up with those tips and make this newsletter the best newsletter that it can be. And that is community news. Next up is the state of CircuitPython, the libraries, and Blanca. This is data that we retrieve from GitHub based on a seven-day period. It runs early in the morning. So anything that has happened today, poll requests merged, issues open or closed are not reflected in the report. But anyway, overall, our numbers were 17 poll requests merged from 14 authors and nine reviewers. And some names that are less familiar to me, Riza Almanda, Mario Broderman, GTB Coding, GarberW, OptionalLion411, AppleCuckoo, and a reviewer name that I didn't recognize was Milo's MNS. So thank you to those people who are newer or less frequent contributors. We'd love to see you chipping in and making CircuitPython better. And also a big appreciation to the people who are steadily working on CircuitPython. Issues-wise, we had 19 closed issues by nine people and eight open by seven people. It's always nice to see the issues number trend down a little bit across our GitHub repositories. And with that, Scott will tell us the updates on the core. Awesome. Thank you, Jeff. Let me just pull it up. Okay. So for the core, we had eight poll requests merged from seven different authors. So thank you to everybody who's contributing to the core. We had six reviewers as well. So thanks again to them. We have 21 open poll requests. So we're comfortably under that one page limit of 25. But a number of these, maybe eight or nine of them are 100 days or older. So we definitely should take a peek at those and see what we can finish. It's always good to have fewer open. A number of these are drafts, but still I'm a numbers person. Issues-wise, for the core, we had eight closed issues by four people and three open by two people. So we're net down five, which is awesome. For a total of 655 open issues, github.com slash Adafruit slash Archbithonyne slash Issues for all of those. Oh, sorry. For Adafruit folks, we have milestones as a method of prioritization. We have one issue for 8.2 stable. We have 37 open issues for 8.xx. And we have 30 open issues for 9.0. So we have our work cut out for us. We have two issues not assigned to Milestone. That number will hopefully have gone down because these numbers were taken overnight. But that's where we're at with the core. Thank you, Scott. And are you going to need the libraries or would you like me to?  Yeah, Ketney had a conflict at the last minute, so please feel free to continue on with the libraries. All right. I can continue. Okay. So numbers for the libraries. This is anything on github that is prefixed with Adafruit underscore-sugar-python underscore. These libraries tend to be run both on the core and on top of Blinka. And we'll go through that. So for library stuff, we had nine pull requests merged from seven different authors. So thank you again to all of those authors. Four reviewers. And number was, it looks like, nine merged pull requests. A number of those were only open for a single day. So thank you to our authors for being responsive there. There's also an issue that was open 81 days and that got closed. So thank you for following up with issues or pull requests that have already been open. Issues-wise, for all of our libraries, we had 55, actually there's 55 currently open pull requests. The oldest is 986 days old. The newest is at a single day old. Issues-wise, 10 closed issues by five people and five open by five people. So net down five as well. For a total of 612 open issues across all of those libraries, 46 of which are good first issues. If you'd like to help with these, there's a great landing page at circuitpython.org slash contributing to help get you started and cover what those issues are. Now, for download statistics, these cover the usage of these libraries in CPython via Blinka. So the total library downloads for 310 libraries from PyPI is 114,658 downloads in the last week. The top libraries are pretty typical with Bust Device being the top and requests up there as well. Request is interesting given that there's actually a proper request library in CPython as well. Library updates in the last seven days. There's one new library in the community bundle or two new libraries, sorry. One from Todd Bot, PS2 controller and an H3 LAS-200DL from J-Pasada 2020. Updated libraries, display notification, Matrix keypad, EPD, RGB LED, MagCal and PS2 controller. And that's it for the libraries. All right. And you talked a little bit about contributing. So yeah, check out circuitpython.org slash contributing if you would like to get a list of all pull requests, all open issues, as well as a list of rather dry library infrastructure issues. If you want to contribute for a first time, this is a great place to start. You can sort the issues by label. So you can search for good first issue if you're getting started or bug or enhancement if we're selling a little more in depth. We have a guide to contributing on Git and GitHub and we're always available to help you get started with things. Here on Discord is a great place to ask. So let us know if you need any assistance. And now to round out the section on the numbers, we will hear about Blinka from Melissa. Hello. Hello. So for Blinka, which is our circuitpython compatibility layer, for MicroPython Raspberry Pi and other single board computers, we had zero pull request merge this week. There are currently three open pull requests amongst the repositories. There was one closed issue by one person and none opened. That leaves us at 94 open issues. There were 13,682 Pi PI downloads in the last week, 6,903 Pi Wheels downloads in the last month, and we are at 119 boards. And that's it. Thank you, Melissa. And next section is called Hug Reports. This is a chance to highlight folks in the circuitpython community and beyond for doing awesome things. I'll start and then we'll go down the list alphabetically to give everybody a chance to participate. And as a reminder, if you're text only or missing the meeting, I'll read your notes when I get to them in the list. I want to give a hug to the community helpers and moderators as we dealt with a moderation issue last week. A hug to Maker Melissa for doing some very thorough testing on a pull request of mine. To paint your dragon for the Protomatter Library and working hard to make it work with circuitpython. And we just had a few things to change about the ESP32S3 support. And finally, a hug to Dan for the newest beta release. It's always nice to see the incremental improvements in circuitpython. With that, I will hand it to Dan and then read notes from a few folks. Okay, thanks. So thanks to Scott for trimming the size of C-stack frames, which is really well... It's going to save a lot of space, I think, in RAM. Not just make it possible for the CPX library to work. I think it'll actually help in a lot of ways. Thanks to Carter, who's been tested out how to update NRF boards that have old bootloaders on them, really old bootloaders that can't self-update. But there are ways to do this that are less trouble than I thought. And we're going to write this up as pages on the appropriate guides. Excuse me. When we get the chance. And thanks to FoamyGuy, who has been looking at some existing PRs and made some of their own, so that the API for ESP32 SPI is more like other network APIs, I think specifically the Socket API. They're sort of needlessly different and kind of non-standard, the ESP32 SPI. And it's nice to see this coming together. It will be a major version change and people will need to update their code. But it's really worth it. Okay. Yes. Thank you, Dan. And a belated hug report to Naradok and to you for help over the weekend with this NRF issue, which I ran into and needed to update the bootloader. All right. Next up, I have notes from David Glode, who writes group hug, especially those working on new releases, new features and synth. And then I have notes from DJ Devin3, who has a hug to Katni for being you, a hug for everyone involved with CircuitPython development in any fashion. Thank you. It's a wonderful language and everyone in the Adafruit Dev community is exemplary. Hugs for JP, Liz, Todd Bot, Gambler and me. Thank you for wonderful bleeps and bloops. One for Naradok for being a Keystone helper with CircuitPython. And finally, for Lady Aida and PT, thank you for everything you've created. And that brings us to FoamyGuy. Hello. All right. Thanks, Jeff. Hug reports for me this week. Thank you to Michael Pokusa and Naradok, who both helped me and offered some discussion around HTTP post request argument formats. Another one, thank you to Naradok, who also helped me this week with some questions about running a server and broadcasting Wi-Fi AP at the same time. And a hug report to Mark Gambler, Tyeth and DJ Devin, all of whom offered up some ideas for troubleshooting some weirdness that I was seeing with USB devices when my PC boots up. And that's what I've got for now. Thanks. All right. Thank you. Next, I have notes from Katny, a hug to Dan H for putting together a rainbow cycle key switch press demo for me when I couldn't figure it out. And a group hug. And then we've got Maker Melissa and Scott. So go ahead, Melissa. Yeah. I just wanted to get back to you, Jeff, for fixing the RGB matrix modules so quickly and group active emails. You are welcome. All right. Scott, what's on your mind? Hello. OK. So hugs firstly to Naradok to Shippu, DJ Devin III and Carter for helping folks on Discord and the Help with CircuitPython channel. Always awesome to see that folks can go there and get help. I really appreciate everybody who does that. And then hug to you, Jeff, for the swirl idea for mounting Stemma and other feather boards on what looks or what was originally a 0.2-inch grid, but you had the great idea of how to add some slots to make it a lot more flexible. So I really appreciate it. All right. And finally, I have notes from Todd Bodd, who's text only today. A hug to Foamy Guy for helping with weird community bundle Gawk bug with PS2 controller. I think Gawk is the name of a program in this case. To Gambler for Synthio testing and to me for Synthio filters. And that completes hug reports. Next is status updates. Status updates is your time to tell folks what you're up to. I will start and we'll go through the list in the document order. When I call on you, take a couple of moments to talk about what you've been doing since the last meeting and what you plan to be up to in the near future. It's also an opportunity to provide any quick tips and tricks relevant to what people are talking about. But if it is lasting more than a few sentences, we'd prefer to move it down to in the weeds. And with that, I will get started. I integrated an updated version of the Protomatter library in CircuitPython. This is the library that makes the Hub 75 style RGB matrices work. And the heavy lifting is done by Phil B. And it's done in a way that we can reuse the library in CircuitPython even though it's designed first and foremost for Arduino. And this version, among other things, had really improved support of the ESP32S3 microcontroller, which is important for an upcoming Adafruit product. And there are pending pull requests in Protomatter and CircuitPython for that. Second item is I've been putting the finishing touches on a non-CircuitPython guide, the Run CPM emulator with RP2040. If you're interested in what that is, I've shown it at least once on show and tell. And next up we'll be working on this Teddy Ruxpin stuffed animal animatronic thing that Lamora has done some engineer segments on, reverse engineering it, and I'm going to help with creating new story files by putting together disparate pieces of information such as the eye movements and the mouth movements and the specially transcoded audio file. And so these other items, the Synthio guide and the MicroPython merge, those will come after that. Teddy Ruxpin will be the next thing that I'm working on and I never imagined in my life that I would say I'm working on reverse engineering Teddy Ruxpin. But here we are. And next up is Dan. Okay, so last week I released Beta 1 of CircuitPython 8.2.0, mostly to get the last bit of Synthio changes in it. There'll be another, we hope to have a release candidate or another Beta really soon for 8.2.0. I started merging MicroPython V1.19.1 into CircuitPython. I went through that and then I said, I kind of realized that I wasn't sure about a bunch of things so I restarted it and will be more careful doing this. This has happened before. It's kind of what you expect when you're looking at a whole bunch of changes that you're not sure what they correspond to. And we do have a bunch of bugs, a bit of a backlog of things to look at to see if we should fix them quickly or not, or more quickly. So I need to look at some of those too. They're a variety of different ones. Okay. Thank you, Dan. I'll read notes from a few people. Then the next person after that will be Tim. So David Globe writes, CircuitPython quickly added a teams mute button to my mouse jiggler with a twist. Control Shift M works on QWERTY, but I replaced M by semicolon for azzer T. The learn guide is Arduino only. There's a link in the note stock. And I found this to help me. It's a link to furscene.com. And yeah, check out those links in the notes document if you're interested in the teams mute button. David goes on to write, I've not been here since months, mostly because I've not written a piece of code since then. I try to stay in sync with streaming or listening to podcasts. And in non-circuit Python, playing with HID remapper on the Feather RP2040 USB host, and wasting time on blocky football programming games at supercollidingball.com, as well as Advanced Wars 1 plus 2 reboot camp. And next I have notes from DJ Devon 3. Who writes, Updated my MQTT featherwing with better graceful fails with Wi-Fi connection, API server fails, or Arduino IOMQTT fails. It's been my main project for about three years and has evolved a lot since starting on an Arduino Uno. Thank you to everyone who has helped me along the way. My participation in the community will become more limited in the weeks or months ahead as I'm dealing with a personal matter. Downsizing where I can and waiting for the inevitable move. Being part of this community has been time well spent. And of course, DJ Devon, we will be here and happy to see you back when you are able to spend more time and absolutely take care of yourself and all that stuff. And now I will pass the talking stick to Fome Guy. All right, thank you. Over the past week I did some more digging into core display I.O. I made many different builds with many different additional print statements added to try to figure out how the internal fields for area, a previous area and current area inside of tile grid behave. I think that I have an understanding of that now and I have also a proposed solution for the issue of the hidden things taking extra time to render. But it is still in my local branch. I need to clean it up and get it pushed into the PR to get feedback on it. So that's what I'll be doing this week for some part of the time. I also did some work over the past weekend, Friday and Saturday tracing through the Request Library as well as PyPortal and Porterbase libraries to figure out more specifically like what happens and what controls what when you download larger files with chunked downloads. Specifically there was some difference in behavior between the two different socket APIs like ESP32 Spy versus the other one. So I have a note down in the weeds to talk about that a little bit more. I yesterday had a much needed personal organizing and putting things away party so I've got a lot of my microcontrollers and things a lot more organized and away now, which is really nice. Outside of the CircuitPython world, I deployed a rocket chat server this week, which is an open source kind of thing like Slack or Teams type environment, but it's self-hosted. You can run it on your own server. It is not really related to CircuitPython, my reasons for using it, but once I did get it deployed and started digging in a bit, I noticed that it does have what looks like a pretty easy to use API. So maybe I will make some things where CircuitPython can interact by like sending in sensor readings into the chat rooms or maybe vice versa, like controlling IoT lights or things like that from the chat rooms look like it'd be pretty easy to do. So that's what I have got going on. Thanks. All right. Thank you. I have notes from Katni. Last week she worked on the Feather RP2040 DVI guide and that is now published and continued work on the Neo-Key Breakouts guide. This week she will wrap up the Neo-Key Breakouts guide, do the TRRS Jack breakout guide, the StemAQT gamepad guide, and the I2S BFF guide. And next we have maker Melissa. Hello again. Hello. So this last week I added a bunch of new boards to CircuitPython.org. I updated the portal base and matrix portal libraries to work on chips other than the M4. I tested and updated the CircuitPython code editor and fixed some CSS issues. And I also updated to work with the latest version of the JavaScript CircuitPython level library. I tested Jeff's RGB matrix and protomatter updates for CircuitPython and I started going through all the matrix portal guides after the changes. This week I'm going to finish going through all the guides and then I'll continue working on some GitHub issues and probably some minor guide updates as well. And that's it. Thank you. All right. Now we have Scott. Hello. So as Dan had mentioned, I investigated the issue with importing the CPX library on the CPX. I did a couple of changes. One, I prevented some inlining into the VM call, like the big VM function. There's multiple, like if you call multiple Python functions that gets called multiple times recursively. So I made that use less stack, which means you should be able to recurse more now after that. I also reduced the max file path link. This is something that's computed during imports and also prevented or has also happened recursively if you're importing one file which imports another file. It can get stacked as well. So there should be improvements there. I rebuilt the PySigRock Pico binaries. They seem to work okay, which I thought they weren't working and now they work, which is great. I added proper board desks for Scorpio and the pirate boards for that as well. And that was the motivation is getting the pirate board supported. I did a detour into KeyCAD generation and created a generator for the swirl mounting style that Jeff came up with. I really appreciate that and I'm excited to see more ordered like 200 of them. So hopefully they came out okay. I'm working on the USB host on the IMEX RT. I did get it reading HID reports, which is great, but I do think I'll wait until after A2 is merged and where it is out because it includes a tiny USB update. This weekend may look into getting it working on the RP2040 feather as well. Friday, I think I spent some time getting CircuitPython building with Clang 16. Clang is the C compiler in the LLVM project, which is a larger tooling compiler tooling project, which is pretty awesome. I did it for Clang 13 as well. So I do want to make a PR this time because I'm making a lot of the same changes again. It's things like all functions need to have void in an empty print sort of thing. And if you're doing a macro to disable or enable, you need to do it in an if macro, not in a C macro that gets the static value. So I'll probably do a PR for that, maybe not with full Clang building, but at least with some of the fixes. My goal is to get a branch building with Clang so that I can go to the LLVM embedded folks and be like, here's the blockers for us. We'd love to adopt it, but this is what we need help with. I'm particularly interested in adding better memory region support so that we can more easily say like this function that writes flash needs to go in RAM and have it implicitly do everything that that function calls as well. Because right now it doesn't, and it's just a huge pain to get right. And I'm sure a source of bugs. I'm looking into Odroid Go issues today, which Dan I think identified as some blockers for 8.2. And then on Wednesday I'm heading to New York to meet up with eight different folks and Dan and have just kind of a vacation as well. I'm back on Monday, so I will be kind of around consistently outside of that. And that's it for me. All right, thank you. And last, I have notes from Todd Bot, who writes, old PS1 and PS2 controllers are pretty rad and cheap. Too bad their connector is bonkers. Not sure how useful this will be, or if it will live here, but Circuit Python Tricks now has a Synthio Tricks section, and there is a link in the notes doc. Two small Synthio examples yet to be integrated into the above. There is a two-voice drone Synth and dueling band pass filters. I've seen the video of the latter one, by the way. That video is pretty cool, Todd. Also links in the notes document. And finally, we'll be looking into potential USB raw HID issues. The USB, excuse me, the lib USB devs are having trouble as they're trying to create repeatable test hardware. And that is also one last link that's in the notes doc. And that completes status updates. Thank you, everybody. It's lovely to hear what you're all up to. And now we will finish up the meetings with the in the weeds section.  Yeah, so I was just looking at the list of open issues on 8.2. I thought the CPX1 was there because I put it there, but apparently this Ojo goes the other one, and I just wanted to briefly have a chance to talk 8.2 release. Because I know Dan's working on the MicroPython merge, so we're going to want to do that after 8.2. Yeah, I was just wondering, we can continue, we might even have an 8.3, because if going to 9.0 takes a long time, we might want to have more stable releases in between, so we might want to kind of stop doing work on main, or else I was thinking of putting the merging, the 9.0 stuff on its own branch, so then we can merge it back or something like that. I mean, I think the question there is, we have good infrastructure for testing the latest main, which I think is really valuable. Yeah. I guess I'm in the camp of let's just move to 9.0. Yeah, the question is, so if we can always backport things to 8.0, right, or have people do it. Yeah. Yeah, for bug fixes. Right, I think we talked about, we don't want to do a pre-release 9.0 until we have the right MPY version. Right, right, yeah. It would be great to get those merge, the MicroPython merges in. Be good too. So I think if you look at the Odroid thing, and as I said in our internal meeting, if we look at what else is on the 8XX list, and see if there's anything that really seems like it is more of a showstopper, which I think not, because it would have been put on 8.2.0. Right. Then we can go ahead and release 8.2.0 soon, like a release candidate this week, or excuse me, early next week or something. Yeah, that sounds good to me. Any other thoughts? So I think there's the possibility that this upgrade in the RGB matrix thing would be disruptive, but Melissa has done a lot of testing, so she tested across all of the different supported microcontroller families. But that's something that, because it'll support this new product, I think we'll want that in an 8.0 and not have to wait for 9.0. But there are ways to manage that, so I don't think it should be a barrier. But I also think it should be resolved this week and all merged. So maybe that would be the thing to hold final for. I don't know. Yeah, we have. Go ahead. I was just going to say, do we have an issue for that? I don't think there's an issue. There's only a pull request. So can mark the pull request 8.2.0? Yeah, I get it. In the milestone list. Yeah. That's a good idea. Thank you, Dan. All right, I marked it. That's it for me, just to figure out 8.2. Our second topic then is from FOMIGuy. All right, thank you. I figured this would be easiest just to ask about because I didn't know the history of the stuff. So essentially, this all relates to the PR that's open in ESP32 Spy, which was an effort to make the socket be compatible with the other sockets, like the built-in socket for the other ports, like ESP32S2 and PicoW, as well as the socket on CPython, I believe, all behaved the same, but they were different from ESP32 Spy. I figured out eventually where the code that I think is responsible for the difference in behavior lies, and it was ultimately in the request library. Some of the code in there is referring to stuff like backwards compatibility, so it will do some check to decide if the socket is backwards compatible or not, and if it is, it will behave one way, and if it's not, then it will behave a different way. I wanted to bring it up, though, like my best guess there was that that backwards compatibility is essentially talking about that different behavior on the ESP32 Spy. That seemed to be the case from what I could tell, but I didn't have any of that actual history or anything to know if that's certain what it was. To go along with that in the request library, there's also some test scripts in the test folder, and some of those refer to, like, legacy tests, like legacy testing the socket, and I was also coming to the conclusion that those legacy tests that have that term in the name were referring essentially to the same quirk. Those were testing to make sure that the backwards compatibility or what I'm thinking is the different behavior from ESP32 Spy, those were testing to make sure that behavior was working. If that is, in fact, the case backwards compatibility and legacy are referring to that difference in behavior in ESP32 Spy, does it make sense to go ahead and remove it entirely, or do we need to try to keep the tests working for that legacy mode, or is it possible that I'm just off the trail and that the backwards compatibility and the legacy are actually referring to something else? I figured it would be easiest just to ask the group if anybody had insight to that. So I think it is the case that it's because of the quote legacy is ESP32 Spy. There might have been some other things that were like that too. You see that pull request, pull 167, I did it over a year ago and it was because I was frustrated by how it was different and it was making eight of requests not work right and it was also there was this random web server code there that wasn't like other web servers and that was also a problem. So I was trying to clean all that up and it kind of got into something larger and then you came along and it looked like it almost worked except it didn't and now you figured out why, which is great. So I think it would be great to continue that. I agree that it should happen at the same time. I was thinking about whether, well, the test for backwards compatibility right now checks whether receive into exists and that isn't a good test anymore but there are some other things that you could test for like realign. But then I thought, but anybody who does this, we don't really want people to update one library and not the other. So I think we should just say that those two things go together and this is a breaking change on both those libraries and we'll release them on the same day and they'll get into the same bundle. Okay. I don't know if there's anything else to test There's Wisnet. Is Wisnet maybe also different and special? I don't know about that. That's a good point. Wisnet, off the top of my head, I think it is its own third case and I think it, well, maybe it's not, maybe that's not the best way to refer to it, but I think that its socket behaves the same as CPython and built-in do rather than like the ESP32 spy did. But I can also test that. I have the Wisnet stuff set up somewhere that I can grab and easily check. Another thing to test, I don't know if it's worth it or not, but it may, whether ESP32 SPI with these new changes now works with HTTP series, the new HTTP series? Yes, I did have that thought as well. I did try it out. It does not work as is. There is an error about something, but I don't, I didn't dig any further just yet other than like trying to run the simple test. If you're willing to look at that, that would be great. Since I made that poll so long ago, part of it was also trying to make the thrown exceptions be the same in the two libraries or in like built-in Wi-Fi and the other thing and maybe there's some updating that needs to be checked. That might be causing some incompatibilities. I don't know. Part of the regularizing of the exceptions was already, somebody already did part of that work. I don't remember the details. If you're willing to keep working on this, that would be great. We'll have a big bang and then it'll be better. We won't be living with this. It's so much trouble and people keep complaining. It's a support issue that ESP32-SPI is different. It would be nice if it was not. Yeah. I can definitely do that. I'll confirm, I will double check the errors that are raised and make sure those match the socket as well. And then I will plan on removing that legacy test then for now to get that PR to pass because that is, I believe, the only thing keeping it from passing. Did you want to try to test the HTTP server on the... I will keep going on that one and see if I can get it working. It also comes to mind the other major socket library would be the MQTT library and whether it has had to work around the differences of ESP32-SPI or whether it didn't have to. So that might also be worth just taking a quick look at to make sure you didn't break compatibility. Yep. Thank you. That is definitely a good thought. I had not considered MQTT. I definitely want to make sure. And like Adafruit I.O. will depend on that as well. Yeah. I think most things that do network are going to do it by importing libraries. There may be another one that I'm not thinking of either, but that's going to be, you know, HTTP is going to be the most of it, requests and MQTT is going to get the next huge fraction of whatever is left. Yep. Okay. Cool. Yeah. I think that gives me the next couple of things to work on, so I should be good to keep going on it. Thank you. I'm excited about this work which I hadn't heard of till now, so I appreciate it. Yeah, for sure. Next up are in the weeds section and so I'm going to wrap up this meeting. This has been the Circuit Python Weekly for June 12, 2023. A big thank you to everybody who participated. Remember that if you want to support Adafruit and Circuit Python and folks like me who work on Circuit Python consider purchasing from the Adafruit shop at adafruit.com. The video of this meeting will be released on YouTube at youtube.com slash Adafruit and the podcast will follow on major podcast services. It will also be featured in the Python for Microcontrollers newsletter. You can visit adafruitdaily.com to subscribe. The next meeting is moved by a day. Next Monday, many parts of the U.S. observe the Juneteenth holiday and so the meeting is moved to Tuesday, June 20 at the regular time of 11am Pacific 2pm Eastern. So we'll see you in 8 days. The meeting is held on the Adafruit Discord, which you can join at any time by going to adafruit.it slash discord. To be notified about the meeting and any changes to the time or day, you can ask to be added to the Circuit Pythonista's role on Discord. We look forward to seeing everybody next week. Have a great week everybody.


Yes, I'm looking forward to this event for fundraising for needy girls in Zimbabwe. I'm originally from there, so I know the need for funding for some of our girls. You know, we have difficulty getting funding, so I'm appreciative of everyone who is here trying to put the effort to raise funds for some of the girls in Africa. This is a lovely idea for the Davis community to be able to do this. I'm here looking at the beautiful artwork and beadwork from Africa. This is what I came for. This is what makes my heart warm and joyful. Hi, my name is Ava and I am in charge of the Silent Auction this year. So everything that we have, all the donations and baskets you buy, all the money will go towards supporting children's education in Zimbabwe. It goes directly to our students, so thank you so much for all your support. Hi, my name is Lachelle May. I'm the wife of the Chancellor of UC Davis, and I'm excited to be here at the Tea for the African Lioness. I am a guest speaker tomorrow, and I look forward to delivering a great message about empowering women. My name is Ida Chen, long time resident of Davis, and I'm just really looking forward to this event because it celebrates women and girls. And yeah, looking forward to the yummy treats. I'm Rachel Starr-Garrison. This is my fourth year coming to the Tesse Foundation annual hats off for diversity, ladies high tea. I'm forward having a good time, but mainly supporting the African students. It's an excellent cause. I'm planning to sponsor one of them myself. In 2017 and 2018, with more than double our scholarships, we raised $12,000 last year. I mean, that's incredible. We could even meet the guys. We don't meet the men. We can do it all by ourselves. We can do better than this. We continue to do the cemetery pad projects with our girls, and some boys also learn how to make reusable cemetery pads. And once they make it, they take it home, and they don't have to miss school anymore. So the video was a few years back before we even started cemetery pad. It was amazing how far we've gone, and you have to come next year to see the follow up to that video. Hi, I'm Judy Rodriguez, and I'm just looking forward to hearing more about the African culture and finding out more about what is going on with girls' education in Zimbabwe. So the video talks about what we're doing. The why is that I am second generation benefit of these functions. So I didn't experience not being able to go to school, but my parents did. And my dad grew up in the village. My mom grew up in a different village. He got married, long story short, he had two wives, and in the middle of nowhere left his two wives with eight kids and died at 38, and left them to take care of their kids. Had it not been for someone believing in my mom, I would not be here today. And so I take that very seriously, that it affects a whole generation. Hello, my name is Joy, I'm so emotional just to be in the presence of such amazing, wonderful women who are doing great things, and I'm looking forward, and I'm honored and humbled to be a part of this. I'm looking around, I'm looking at the resumes, and I'm looking at the work that these women are doing all over the world, and I'm just honored to have their light touch my life. And I'm looking forward to meeting more people to see how I can join this vision for what we can do to continue to change the world one child at a time.


This is stock number 7J269A. We are here at Summit Automotive in Fond du Lac, Wisconsin. Your new and used Jeep Wrangler headquarters. Today we are checking out this super clean 2017 Jeep Wrangler Unlimited Sport with the Willys-Wheelers package on it. From this HD video you will be able to tell that this Jeep is extremely clean all the way around inside and out. The Willys-Wheeler package comes with the 17-inch painted alloy rims. You got the little Jeep logo painted on there and they come with BFGoodrich mud terrain TA tires. You can see that they have probably about 70-80% of the tread left, maybe even a little bit more. Framing underbody is very clean on this vehicle. We shoot all of our videos in 1080p so if you have HD capabilities on your computer tablet or smartphone device turn them on now because it's like you're right here looking at the vehicle with me. Also on the Willys-Wheelers edition you get the gloss black center bumper piece, factory fog lights. You get the gloss black grille and the painted black Jeep letters on the front grille there. This vehicle has the 3.6 liter Pentastar V6 motor which has been on Ward's top 10 engine list several different times. The passenger rim is very clean, no scuffs or scrapes on that. See the front fender is in excellent condition and as you go down this side of the vehicle you can see just how clean the body is, how reflective in glass like that paint is. So the Willys-Wheelers package is actually a sport so it's a sport grouping for the trim level and then Willys-Wheelers is a package within the sport that gives you you know the gloss black rims, the gloss black bumper pieces. You also get the rock rails on the Willys-Wheelers edition, didn't see any denser dings down this side. The vehicle that's really why we take these videos so our customers can see just how clean the body is on these vehicles. You can see it does have the locking lug nuts which we do have the key for and the back rim is in excellent condition and the back tires have just as much tread as the front tires. You can see the frame and under body on this vehicle is in excellent condition. It's like that all the way underneath, did have a little bit of snow here recently so we got a little bit of splash up on it. Rear bumper is in excellent shape, no dense dings or scuffs on that. Here's a brand new tire that's never been used so you can kind of gauge the tread on that to the tread that's actually on the tire so lots of tread left on these tires and that rim is matching as well. Take a look at the back here so it has the all weather Alpine subwoofer and sound system. You can see the back storage area is very clean. There is a little bit of a storage area underneath here where you can put your door hinge bolts and you can also put your roof bolts in there. Speaking of roof bolts, there they are, there's one, two, three on that side, three on this side and then there's two more on the top.  That's why Wranglers are so popular in summer and winter. As we go down this side of the vehicle just as clean as the rest of the vehicle, passenger side rims absolutely perfect. Hard top is in excellent shape, no scuffs or scrapes on that. All the fenders look really good on here and the doors are in excellent shape. All the hinges, there's no corrosion or anything, they all look really good. The Willys-Wheelers or Sport Package gives you the black cloth interior. There are no rips or tears on these seats, very, very clean. You can see there's no rips or wear. It does have a driver's seat height adjuster. The Willys-Wheelers comes with the all-weather floor mats. You can see that the carpeting is nice and clean underneath there. This Jeep has 9,229 miles, comes with a compass temperature mileage display. This one has the leather-wrapped steering wheel with the Bluetooth audio controls. Steering wheel is in excellent shape, cruise controls on this side. Comes with the 430 radio, so you have AM, FM, Serious Satellite radio capabilities. Then you also have a hard drive which holds up to 28 gigabits of music. You have your 5-speed automatic transmission, 4x4 shifter on the floor. Stability control, downhill assist control, and then of course your climate control right there. These are for your windows, so you've got power windows, power mirrors on this one. Not all of them come with that. Passing your seat is very clean as well, no rips or tears on that. Smells very clean in this Jeep, I don't think it's ever been smoked in. Top roof pieces are in excellent shape. And of course we've got the all-weather floor mat on that side as well. You can see it indeed does have the Alpine sound system. We'll take a quick look at the back seats and then we will check out under the hood. Back seats just as clean as the front seats, no rips or tears back here. Very nice condition, it does have the all-weather floor mat back here. There are those locking lug nuts we were telling you about. This is a latch child safety system for car seats, and you can fit car seats back here. I do in my Wrangler. And you can see that those seats fold down for extra storage, almost completely flat. And once again, very clean back here. This one was locally owned here in Fond du Lac. Actually by one of our salesmen. Joved it brand new and traded it in on a brand new one. The hood is very clean, no dents or dings on that. Always serviced here as well at Chrysler Summit Chrysler. See the engine bay is very clean, runs very smooth. This vehicle has gone through 130 point inspection by our Chrysler Jeep certified technicians. Has a fresh oil and filter change, all the fluids have been checked and topped off. And this Jeep is 100% ready to go. Highly recommended from a condition and quality standpoint. Very nice all the way around, very nice on the inside. A lot of nice options for the Sport Willys-Wheelers edition. And to see more pictures of this one or one of our other 400 new and used cars, trucks, SUVs, minivans, Wranglers, you name it, we got it.  All that we have all at www.summitauto.com. Thank you so much for checking out the video. If you want to make this one year, give us a call right now,<PHONE_NUMBER>. Ask for one of our sales associates to make this one year today. Once again, that is<PHONE_NUMBER>. Thanks again. If you like it, want to watch more videos, go to youtube.com. Remember to like, subscribe, and share on those and this video. In fact, in a second you'll see a link to subscribe to our YouTube channel on your left. A link to more used Wrangler videos like this one on your right. And if you haven't been to our website on the bottom, a link to this vehicle on our website. Click those, check us out. We really look forward to help you with this super clean 2007 Jeep Wrangler Unlimited Sport Willys Wheelers. Thanks again.


I'm Rachel Myers. My talk today is called Stop Building Services. I'm going to do a quick intro about myself. I am on the board and a volunteer with an organization called RailsBridge, which holds free workshops for marginalized people around the world. We are trained to teach Ruby in Rails. And a few years ago, we realized that we should split off some of our back office functions so we could do bridge foundry. And that supports Clojure Bridge and Mobile Bridge and all the bridges. So get in touch with me if you want to help out with RailsBridge or if you have a technology that you want to get into the hands of marginalized people. I can help. Another side project is, along with a coworker at GitHub, Jessica Lord, I've gotten really interested in getting great dev environments running on inexpensive hardware like Chromebooks, because it's a thing that can make programming accessible to so many more people. So if you are doing something like this or you want to start doing something like this, get in touch with me. And my day job is as a Ruby engineer at GitHub, I work on the new user team. So we're focused on improving the platform specifically for people who are joining GitHub when they learn to code. So my talk today includes Star Wars jokes. I am either happy to tell you or sad to tell you that the whole talk is full of bad Star Wars jokes. So both because of the Star Wars jokes and because I'm seeing something that might be controversial that we should stop building services, I brought tomatoes that you can throw at me if you just like them. So I'm gonna hand these to our MC. Raise your hand if you need to throw a tomato and he can sort that out for you. Please don't really hand out any tomatoes. So I'm also going to use a lot of Ruby examples, but this isn't just a talk about Ruby. I think this is a talk about how we're making technical decisions. So in general, my thesis is going to be we need to be more thoughtful about how we're building services. And we can't just say build more services, build smaller services forever. At some point we have to start talking about why we have problems. So just to make sure we're all on the same page, service oriented architecture or SOA for short is a style of software architecture that deploys distinct services in place of a single monolithic application. And outside of Ruby and Java for example, this has a long history, but it's a relatively new thing for Ruby and we're still kind of finding our way. So in Ruby, service oriented architecture mostly became popular because Rails apps make it really easy to go fast to build a lot of code at once. And that can mean that you can get a large application and that really can become hard to manage. So we've kind of told ourselves some mantras that led us to build services and those are things like monoliths are big. Yes, fine, monoliths are big. I give you that one, that one's true. Monoliths have a ton of code and because of that they can be hard to navigate. And it's probably true that in a large application there are parts of your app that are badly factored. That can make it confusing. Another thing we tell ourselves is that monoliths are hard to change. That might be because you had a bad abstraction when you started, over time you stick with it, you build things around it. And when you wanna correct that, now it's hard to change. We tell ourselves that monoliths don't work for big teams. This means if you're responsible for one size of the app and someone else keeps making changes to your app there's not a very good way in a monolithic app to enforce that boundary. And just to give you a foreshadowing of what I wanna say, it's kind of rude to like, if you separate your repos and you have a separate service it would be kind of rude to make it impossible for a team member to have commit access on that. That's all I'm gonna say. You probably have an organizational problem if you're doing that. So we also say that monoliths make apps slow. And I don't think this one is defensible in the end but there could be situations where if you had workers that were dedicated to just a subset of requests then you could scale up just that section and that might make it faster. So that's something we've told ourselves. Monoliths aren't web-scale. This is just a troll, this is just me trolling. If I had 14 different micro applications I could scale them up so well and then I would be web-scale. I think that's what this means, people say this. So these are all things that I'm mocking now. I'm mocking them but if you were to have asked me what the ideal application architecture is in 2012 I would have told you all these things. I was a true believer. So I come and I say these things mocking myself. And all of the examples I'm gonna give today are examples of things that I did that I now look back on and think were bad decisions. So this is not me picking on someone else who is a hapless person who just stumbled into my view. This is me, I'm confessing my sins. So before I jump into what I've done badly I wanna talk about how we should make architecture decisions because again I've made architecture decisions and now I regret them. So if you had asked me back in 2012 what should we think about when we're making architecture decisions? I would have said any one of these things. I would have given you mantras. And the point I wanna make here is that mantras are not what we need when we're making architecture decisions. We need reasons and we need evidence. So I wanna introduce the idea of falsifiability. This is an idea that comes from philosophy of science and was specifically put forth by Karl Popper. The idea is that there is some evidence that could cause me to change my mind. So if there is evidence that could cause me to change my mind that idea is falsifiable. And if there's no evidence that could cause me to change my mind that belief is not falsifiable. And I put forth that all of our architecture decisions should be falsifiable beliefs. We need to be convinceable. We can't just rely on mantras here. So I used to have non-falsifiable beliefs and eventually I changed my mind. So this is a form of my talk today. I'm going to, so I propose that we should make decisions based on evidence. Controversial. I'm glad you laughed. Next I'm going to suggest what we should look for when we look at our evidence. What our criteria should be. And then I'm going to walk through case studies because I take that as like a kicking off point for looking at evidence. And then at the end I'm going to find, I'm going to try to pull out some conclusions. Things that I think we could use as principles going forward. For example, we should group together in services things that are going to change together rather than pulling them apart into distinct services. We should think about the differences between libraries and services and be careful when we start mixing those two strategies. But I'll get to that. Right now, what should we look for when we look, when we try to judge our architecture? I think it should meet three criteria. Whatever we choose for our architecture should make our product more resilient and fault tolerant. It should make it less fragile. We should prefer architectures that let us better withstand and recover from failures. And we should avoid anything that introduces new fragility that isn't absolutely necessary. Secondly, we should prefer architecture that makes working on and improving the product easier. If it's easier to understand and debug and improve a feature in one architecture, that is a better architecture. And lastly, our architecture impacts the ability to work together on teams. I'm sure we've all heard of Conway's Law. That's the idea that the structure of an organization can be mirrored in the software design that's produced by that organization. As an example, if you have a lead architect that and all of the other teams take their orders from lead architect, you might get a main app that doesn't do very much, but it talks to a lot of services. And the services themselves don't talk to each other. Or within a single app, you might have three different teams that own different verticals and maybe only two of them need to talk to each other. So you might get something that looks like that. So it's important to keep these things in mind as we go through. So I'm gonna put this nice border around this slide so you can remember it. So those are the criteria that I think we need to look for. And that's what I'm going to pay attention to but when I go through these case studies. And now all the case studies, the explanation of all the ways I have messed things up. And before I get to that, I need to clarify, I'm an engineer at GitHub and these are not stories from GitHub. On the whole, most of the experience that you see when you go to github.com is a single monolithic Rails app. And we do have some services like our metrics collection service. But most of our app, even things that aren't core functionality live in our main app. So that's things like notifications, the framework to do A-B testing and audit logging that all lives in the main app. So the first case study is what I think a lot of people considered the perfect use case for services. A team I was on got a feature request for a neglected part of the website where the code was much more tangled than other parts of the app. And this was a feature that allowed people to vote on things that they thought should be sold in the application. And this, excuse me, this is a really common feature for e-commerce sites because people think if they voted for it, they'll buy it. That's not always true, but it's convincing. So here's what happened when we tried this.  It's really true. It mixed behavior, presentation and obscure browser fixes, sometimes all in one line and there were hundreds of lines like this. And remember, this is a feature that is fairly simple. It's voting yes or no. That's all it does. So there's no reason that it needs to be like this. Sometimes we didn't understand if the browser fixes were even for browsers that we still supported. There was never any indication of the intention behind lines and there was absolutely no structure. So in some cases, so we ended up deciding that this JavaScript was unrefactorable, which is a fascinating concept in retrospect. That's what we decided. And the server side code had a different problem. I've recreated some code to kind of like describe what the model was. I've created a hat domain model. So there are hats that could be voted on, which were not yet products in the main site. And there were the hats that you could actually buy, even though the behavior of the two is entirely different. And there's this interesting thing where you could, where we created an association between the two things that were the same type of objects and had two entirely separate behaviors. So this is a pretty confusing data model. And if we had been following the advice for managing our complexity that Sandy Metz would put forth, for example, we would decide that we're violating the single responsibility principle. And we would have refactored these to be two separate classes, one that can be purchased and one that cannot be purchased, one that can be voted on. But we thought that building services was an alternative approach to managing complexity. And we thought that we'd be able to refactor as we rewrote the services. So we didn't bother to refactor this in place. So here were our project goals. And by the way, this is Icarus, the boy who builds wings out of wax and tries to fly to the sun. Just this is foreshadowing, huh? Okay, I got the name wrong. And so this is meant to show you what is going to happen. Going to fall to the ground. So we needed to make a small improvement to the feature. And we saw this as an opportunity to refactor and to manage our complexity. So here's what we did. We started with our main DB and our main app. And then we created a service and gave it a new database. And then we did one bad thing, just one bad thing. We connected to our old database so that we could get information about the existing hats. And this should have been a warning sign for us, but it wasn't. And then we did another bad thing. We realized that the main app also needed to know some attributes about voteable hats. And we couldn't wait until the API was built. So the main app connected to the voting hats database. And we should pause here to appreciate that this is the diagram of doom. If you end up here, if you ever draw this, stop what you're doing and stop doing that. Don't do this, never do this. This diagram means that we didn't understand the code that we were extracting well enough to actually extract it, well enough to see the boundaries. So we drew the lines around our new service poorly. Instead of creating a new extracted service, we created an ecosystem of services that mirrors our poorly factored code in our original app. Then we did another bad thing. Realizing there was so much complexity in the hat model and its associations and not being willing to spend time understanding that complexity, we packaged the hat model and associated models in a gem and then we included that gem in our main app and our service. I swear, I make better decisions now. I'm just telling you about it anyway, it's fine. So the first failure here is that we drew the wrong lines around our services. And this is a huge danger that I think is not discussed when people are talking about services. So creating classes with well-defined responsibilities is a precondition to ever trying to build a service. And more importantly, services are not an alternative to managing your code complexity. Teams that are driven to write services because they have gnarled code in their current app are not going to succeed. So if you have unmanaged complexity, the thing to do is to refactor that, to work on that until it's something that you understand and have a handle on. And then you should see if you still want to make a service. And just to like drive this point home, we locked in our bad code with architecture. I drew those databases, by the way, with keynote drawing tools. Do you like them? Second, and it took me a while to realize this, but now it seems quite clear to me. Services and libraries are trained to do two different things. A library is a way of caching behavior in your app, and a service is a way of extracting behavior out of your app and making yourself not responsible for it. So if you find yourself extracting services and then sharing libraries between them, I now, when I see that, I immediately know that something has gone wrong. We drew the boundaries incorrectly, or we haven't fully extracted behavior, or there's some core functionality that we think we need everywhere, which sounds to me like not the right boundaries. So coming back to this list of things that I went from architecture. This project is really focused on helping us improve the code. It's a number two. And I think we failed. We didn't make it easier to understand and improve our code in the future, or create a more nimble application. We made it worse. It became harder to understand the code and to change our code in the future. So to talk about how this is handled today, GitHub is a giant monolithic Rails app, and there are corners of it that are neglected and poorly understood and not tested or poorly tested. So that makes it very risky to refactor, but it also makes it absolutely essential. So to help with refactors and rewrites like those cases, we maintain an open source project called Scientist, and Scientist lets you define an old code path and a new code path and run those both in production. So you get to report back when they disagree, and you can investigate those disagreements, resolve them. What maybe the old code path is right, and you found an edge case that you need to account for in your new code path, or maybe this is a bug in your old code, and you'd be surprised how often you find those. So you get to dark ship your code and test it with real users without impacting the real users. And if you want more information about this, Jesse Toth, my co-worker wrote, gave this really great talk called Easy Rewrites with Ruby and Science. In her case, it's an explanation of how she wrote all of the permissions code at GitHub. So she went through every corner case that she was getting for months, and in the end she shipped code that was tested and reliable and well factored, which was the exact opposite of what it was before she started. So it was a very impressive rewrite and almost impossible to do well. So it's a great talk. So second case study. We started building on these services, and we decided to build out a service that would manage all of our authentication and authorization, because as we imagined ourselves building lots of applications and everyone needing to authenticate. So this seems like a natural first step. And it was also enticing because our complexity was concentrated in our God model, the thing that our app is about, and in our user model, and this would pull out all of that user code. So it sounded enticing. I should say that it was about pulling out the complexity of our user object, because not all of the complexity of our user object was in the user model, which is part of the problem. It was actually, the user objects were actually modified in a lot of places. So we also had a second problem. And we were beginning, we were at a size when we were starting to have problems with team ownership. First, teams that consumed the API or had feature requests for the API would sometimes just make their own changes in the API without consulting the teams that were responsible. And secondly, we were seeing more and more of people making proposals for code that they weren't responsible for, and then zooming off. I now call this the swoop and poop. They're like a sequel. It's not cool, don't do it. So this was especially problematic for the team that was maintaining the users, and extracting that code seemed like it would give us complexity management and the organizational separation that we really wanted. If I look back at what I want from architecture, it's focused on number two and three. Encourage the understanding, debugging, and changing of code in the future, and help teams work together better. So here's what we did. We learned from our past mistakes and we didn't create a new database. We pointed our identity service at our existing main database, and when a request would come in, it would go through the main application, which would call the identity API to the database, and then it would return a response. So it's a little circuitous, but it's not the worst thing in the world. And when we first deployed it and it started working, it felt great. It was working. We were running services. We were living the dream. It was like this. I'm way more entertained by my jokes than you are. It's fine. So around that time that we were creating our identity service, we also launched an iOS app. And the iOS app would need to authenticate users just like the main app would. So you might hope that authentication would work like this, a request would come in, the iOS app would call the identity service, which would hit the main database and return a response. But again, the user objects were modified in places across the application, and we were never able to fully extract all of the user behavior into the identity service. So as a result, the identity service needed to call back to the main application and the identity service for every authorization or authentication call, including those from the mobile app. This is a failure. We created the identity service. We ran the identity service, but it couldn't do anything on its own. And we accidentally created something that was much more dangerous. First, we brought on ourselves a lot of non-trivial operational complexity. And now we had one app that we needed to skill up and it was called frequently. You have to know things about the users on almost every call, on almost every request. So we added a lot of database hits too. But more seriously, the identity service wasn't capable of functioning without the main application, and the main application couldn't function without the identity service. So both applications needed to be up all the time for the site to be usable. So instead of one single point of failure, our main app, we now had two. So a problem in either app would bring us down. It would devastate us. If you can indulge me in a little bit more of Star Wars humor. It's like the droid command ship. Do you guys remember how the droid command ship goes down? There are all these fighters trying to hit the droid command ship and it has its shields up. But then Anakin crash lands on it somehow because RTD's used with him and he saves the day every time. And so he crash lands in the droid command ship. He accidentally fires the gun on the ship as he's trying to take off. And he takes out the main reactor of the ship and all the droid stops. So the jet is like, wow, wow, wow.  That is what we created here.  So we're still, the identity service wasn't relieving the load that was on our main app in any meaningful way because it was still hitting the main database. And we had more network calls than we had before. So it's common to hear SOA touted as a way to reduce upload and in so doing to help scale applications. But SOA in scaling is very subtle. This is how I learned about queuing theory. So to just give you an overview, starting out we naively believed that anything that would help us reduce load on the main app would help scalability and our server response times. For example, if we had 1,000 workers in the main app and we added 1,000 more workers to handle just authentication, that seems like it would be an improvement. But the identity service could still create a bottleneck for us because it's like a coffee shop where you have to stand in line to order your coffee and then you have to stand in line to pay for your coffee. You have to stand in line to pick up your coffee. And with the monolith I just have to stand in one line. So it really is possible to scale up that multi-line coffee shop and get your coffee just as fast as it is with like one line. But it often requires hiring a lot of people and really optimizing your flow there. And it's not as simple as just like creating a new service, adding workers, it's done. It usually is not that simple. So in cases where there's a difference in priority or where there's not a difference in priority, it's often faster to have just one large pool of workers that can respond to any requests. And of course that changes if you have different uptime requirements. And additionally, we had to consider the time for network calls. In our case, we had to go back and forth between the identity service and the main app quite a bit. So we had a lot of network calls. And in the case of the identity service, for the same amount of resources, we could get an average response that was faster if we had a single pool of workers. So that calculation definitely changes for services that are used less frequently or that could time out without devastating the user experience. So in terms of our architecture standards, we made the experience more fragile and less resilient. And we have two single points of failure and added operational complexity. And then we had our other goal of defining clear team responsibilities. And I think the result here was an attempt like we got started, but it wasn't a clear win. It didn't solve our core problem of teams not respecting each other's responsibilities. And I don't think that we should totally rely on software to do that. I think a lot of it is an expectation that you have between people. And I can't say that we at GitHub do this perfectly, but I'll show you our solution to this problem. Every controller class sets a team that is responsible for it. And those values are pushed along with the errors into our error tracker. So in my error tracker, when I view it, I can see all the errors that I'm responsible for. And because I'm going to see those errors and I'm going to be responsible for the errors that happen there, that also creates the expectation that if I make changes in a part of the app that I'm not responsible for, if someone makes a change in the area I am responsible for, we should get each other's sign off before we merge those changes. So case study three. This one was not destined to be a disaster. The implementation made it one. So when we had a monolith, we needed one set of assets for the website. Soon we had a mobile web experience and lots of services, we had a few native apps. Maybe now they have a watch app, I don't know. So we need to find a way to share all of our assets across all of these applications rather than repeat them. These are things like the header, which was visible everywhere. We had a login modal. If you do things like e-commerce, it could be size charts, anything where you want to share things that our customer are facing. So we had one main goal. We went to avoid repeating HTML, CSS, JS, and images across all of our apps and services. We at least wanted to make them available for all of those things to use as they saw fit. So we could have done this by copying and pasting things that doesn't avoid repeating, that's repeating, but we thought we could be more clever than that. We thought of our handy, cheap solution that I think every Rubyist jumps to, we thought we could make a gem, and then each of our assets could just fetch that gem and pull it into its own library, or pull it into its own code. So I'm using a gem here to indicate a library, but I think the exact same thing applies to any libraries in your app. If you use Bower packages or MPM packages, the same principle will still apply. So here's how it went down. Each app would include the gem and pull all of those assets, and this was very cheap because it's very easy to do and it's easy to reference all those assets in your code. And the trouble came when the assets needed to change. So this is like just a generic gem prime or whatever. And when the assets change, those are sometimes dramatic customer-facing changes. And in those cases, we want to update all of the assets everywhere. That's not how gems work. So imagine that each of these services has a UI component associated with it, and we increment our gem version. We then needed to coordinate updating all of the applications, and somehow, magically, redeploying all of those apps at the same time. That's not how deploys work. So this was a really interesting failure. We drew slightly better boundaries around things, but we still got it wrong. We didn't draw just the right boundaries. And we still came to really regret this architecture. Sounds good. So what went wrong here? This became a huge pain point because our deployment workflow made it hard to make these changes. And we forgot an important business requirement that the assets need to change uniformly. The solution would have been okay if the boundaries had been different for the services. For example, if assets for a single user experience all came from the same place, I think this would have worked. For example, if all of the assets for the entire web experience had been in one service, that would have worked. And because these apps needed to move together and needed to change together, it made it harder to change our assets, eventually, at all. We had to do a lot more coordination up front. And finally, when people joined the team, they weren't able to just jump in and contribute automatically. In a monolith, you always have the ability to search through a project and find something. And once you start creating services, you have to start doing a lot more documentation. We had a lot of people who would find the header, start changing the header, but it was rendered, right? They were changing this one version of the header. And we weren't going to re-bundle those when we deployed. It was coming from the gem, so that didn't work for them. So it was an important lesson that we needed to rely on documentation instead of just trusting people to search and replace things. Going back to this, to our standards for architecture. This project was really about code quality, about making it easier to update assets rather than copying them, so the second requirement. And I would say that although we did avoid having to repeat ourselves, it came at a bigger price than we expected. We needed to really ramp up our documentation game. And because deploying changes were harder, we ended up finding it hard to change anything at all. Also, no one told me that when I started building services. I would just like to say to all the people who wrote blog posts back in the day, you didn't say that. So, although this wasn't really terrible, and it wasn't a dangerous change, like the identity service, we didn't really get what we want, and I would consider this a failure. So I would like to indulge in going through what some alternatives would have been for this one. In retrospect, I think the point about services and libraries doing different things applies here again. We could have built something that would change uniformly. For example, if we had an asset service instead of a gem, so it's not being cashed in the service, it's calling out to the service for all the assets. That would have helped us update the services, but it wouldn't have helped us deploy those changes. So it would have been an incremental improvement. I think an even better solution would have been to create a front end that contains all of our assets, and then a back end, and that would also have helped us with our native apps. So I just worked my way around to very standard architecture. There you go. Also, monolithic apps don't have this problem, but they can have similar problems. You can architect your monolith in such a way that you run into similar things. At GitHub, we package up our assets, and we use them across several applications, and we do run into pain points around versioning and incrementing those, but this is very crucial. It's not a customer-facing problem. The entire customer-facing experience is served from a single monolithic Rails app. All of the other apps that include these packages are internal apps, and we include the core JavaScript and CSS so that everything that we have feels get hubby. But those apps don't need to change at the same time as the customer-facing apps. So one last use case. This is about failing gracefully. The point, at this point, I've given a version of this talk before, and people came up to me and said, yeah, it's weird. I don't know why anyone would ever build a service, which I felt a little bummed by because I never had that insight. And so I'm going to present a case where it kind of worked out okay. So I was not working on a social website, and I was not working on a social network, for example, and we got a request for social features. So say this is our website. I had a lot of fun making the slide deck just in. This is what we consider essential for our customers to shop, and then we got a feature request for comments on this page. So in this case, they're just commenting with fuzzy JavaScript screenshots. It's fine, it's fine. So the first thing that we wanted to accomplish when we were building this out was that we didn't want to impact the core functionality of our site. This is a bonus feature. This isn't essential to using our website, so it has very different uptime requirements. If the comments go down, or they get slow to the point that we're just going to time out the request, that's fine, our site is still up. And this fits exactly what our first requirement for architecture is. We want to increase our reliability. So we built this out as a separate comment service. We could build it as a comment service, or we could build this as part of our monolithic app. If it's part of the main app, then we need to make sure that we Ajax the request, or that we create the content after the page loads, or paint the content after the page loads. And maybe we should relegate comment creation to a background job, and we should set strict timeouts to make sure that if we're fetching a bunch of comments, we don't take up too much time, all those things. Or we could build an identity service and get a lot of that for free. We're automatically going to get that isolation that we want. And if we're only building an API that returns, for example, comment JSON, then it's very independent. So we ended up building this as a separate service, and it worked okay. And I don't have any failures to point to. All I have is grumpiness. So my grumpiness is this. There were some details that we had to mine, and the client of the service has more to do here than the actual service does. We had to compromise on when we would repaint the page, because we wanted to avoid that. We ended up doing it below the fold, so most people wouldn't know. But I still think there was a pressing need for it to be a separate service. As it is, it's fine, it runs, it functions, but now we have two apps to keep up all the time, and it doesn't have to be up all the time, but you still have to always think about it. So why do that? Why? Grumpy Rachel says why. So, going back to my architecture requirements, we specifically went to focus on fault tolerance, and I think that worked. That being said, why? We could have done that, we could have done it other ways. So we're almost done. I have some conclusions. I started by proposing that we should make architecture decisions based on evidence, wild. Next I suggested what we should look for in our evidence. Then I went through some evidence, and now what do I conclude?  If you successfully untangle your code and you still want to do SOA, I feel like you've earned it at that point, but I bet you won't get there. Secondly, don't ignore your points of catastrophic failure and the fewer of those that you can build, the better your life will be, the happier you will be, the happier ops team will be, everyone will be happier. This is simplistic, of course, because everyone has a few points of catastrophic failure and it's hard to ferret them out and find them, but the goal really should be to minimize them and we have to think about this when we're building our services. And lastly, there will be parts of your app that need to change together, and you can save yourself so much pain if you think about when things will need to change together beforehand, and you pull those into the same service. And now, a non-star Wars joke. I think a lot of the impetus for building service-oriented architecture comes from frustration with code quality, but services can make those problems worse. So the first step is to focus on your code quality inside your monolith. And my one message, if you can only have one message, if you don't get to have all my messages, if you get one, take care of your giant robots, take care of it, it's great. And so with that, I got some amazing drawings from ExplodingDog.com, which is drawn by Sam Brown, and I went through and I drew skirts on all of them so they're cooler. And I got all my Star Wars memes from Memesinner.com, the fine website and institution. And if you agree with me or you disagree with me, please, I'm happy to argue with you civilly or just chat about these things. I'm Rachel Myers. Thanks. Thank you, sir.


To begin the room selection phase of the housing contract process, log in after you have done previously in the housing contracting portal. If you have completed the previous steps in the process, you may click Save and Continue on the Phase 3 completion page. You will have two pages to complete prior to room selection, the Confidential Contract and Safety Addendum pages. On the Safety Addendum page, read each of the statements and enter your initials under I Agree. When completed, click Save and Continue. Then complete the Meals Plan selection. Select your meal plan from each semester by choosing from one of the options available on the drop-down menu. Except for residents of the Duncan Avenue Apartments, all students living on campus in a residence hall must have a meal plan. If your roommate has already selected your room, you will continue to the Room Assignment Status page. You may review your assignment, confirm to keep your assignment, or choose to change your assignment for you and your roommate. Continue to the end of Phase 4 if you do not wish to change your assignment. If you do not already have an assignment, you will arrive at the residence hall selection page. Select a residence hall to see all available rooms in that building. Once you have found the room you want to select, click on the Select Room option. If you have a bonded roommate and select a suite style building, you must select the number of rooms applicable to your group. For example, if you select Clark Hall, you will have to select one other room. You will need to select Clark Hall 103E and 103F. Note the floor map is available by clicking Show Room Info when you have selected a residence hall. If you have a bonded roommate and select a traditional style hall, like Pomfort Hall, you only need to select a room that shows 2 out of 2. This means the room is empty. Click Save and Continue at the bottom of the page. Next, you arrive at the Assign Beds page. Assign yourself and your roommate to the individual bed spaces within the room. You will notice that you have 10 minutes to assign yourself and your roommate to a bed space in the room. While the timer is active, this bed space is held and not visible to other students. Finally, you will arrive at the Confirmation page where you will confirm the room assignment for you and your roommate, if applicable. Click Save and Continue if you wish to change your assignment. Please click back on the Safety Addendant page. Hit Save and Continue and then you may change your room assignment if beds are still available for you and your roommate. You have now completed Phase 4 of the housing contracting process. After completing Phase 4, students are encouraged to click on my details in the upper left-hand corner where they can confirm their room assignment, roommate, and meal plan selections. If you have further questions, please contact the Housing Office at housing at uark.edu or<PHONE_NUMBER>.


Great, great. It's been a process, especially with the Frenchmen and stuff. Trying to get them intrigued with our offense and everything clicking. In season, we expect to get back in the conference championship and have our first playoff birthday at University of Plattenville. Take one game at a time, not to overlook anybody. Of course, come out with a conference championship and make a playoff birthday and go for the national championship.