Welcome to the presentation of the STM32H7 DMA Request Multiplexer, or DMA Mux. It covers the main features of this module. The DMA Mux Request Multiplexer allows routing a DMA request line between the STM32H7's peripherals and its DMA controllers. The routing function is ensured by a programmable multi-channel DMA request line multiplexer. Each channel selects a unique DMA request line unconditionally or synchronously with events from its DMA Mux synchronization inputs. The DMA Mux may also be used as a DMA request generator from programmable events on its input trigger signals. DMA Mux main features. Up to 16-channel programmable DMA request line multiplexer output. Up to 8-channel DMA request generator. Up to 107 DMA request lines and synchronous operating mode. Per DMA request generator channel, DMA request trigger input selector, DMA request counter, and event overrun flag for selected DMA request trigger input. Per DMA request line multiplexer channel output, up to 107 input DMA request lines from peripherals, one DMA request line output, synchronization input selector, DMA request counter, event overrun flag for selected synchronization inputs, and one event output for DMA request chaining. The DMA Mux request multiplexer enables a routing DMA request line between the STM32H7's peripherals and its DMA controllers. The routing function is ensured by a programmable multi-channel DMA request line multiplexer. Each channel selects a unique DMA request line unconditionally or synchronously with events from its DMA Mux synchronization inputs. The DMA Mux may also be used as a DMA request generator from programmable events on its input trigger signals. The assignment of DMA Mux request multiplexer inputs to the DMA request lines from peripherals and to the DMA Mux request generator outputs, the assignment of DMA Mux request multiplexer outputs to DMA controller channels, and the assignment of DMA Mux synchronizations and trigger inputs to internal and external signals depend on the STM32H7's implementation, referred to the STM32H7 reference manual. The DMA Mux request multiplexer enables routing a DMA request line between a peripheral and a DMA channel in unconditionally operating mode. When the multiplex is set, it ensures the actual routing of DMA request acknowledged control signals. The connection of one peripheral request to the multiplexer channel's output is selected through the programmed request ID in the DMA REQ ID field of the channel control register, or DMA Mux CXCR. For each peripheral request line an ID is assigned. DMA REQ ID equals 0X00 corresponds to no DMA request line selected. After configuring the DMA Mux channel, the DMA controller channel to which it is routed can then be configured. It is not allowed to configure two different DMA Mux channels to select the same DMA request source. Each DMA request line multiplexer can individually be set to synchronous operating mode by setting the Synchronization Enable, or SE, bit in its corresponding Multiplexer Channel Control Register, or DMA Mux CXCR. The DMA request router has multiple synchronization inputs. The synchronization inputs are connected in parallel to all multiplexer channels. When a multiplexer channel is in synchronous operating mode, the effective connection of the selected input DMA request line to the multiplexer channel's output is conditioned with events on the selected synchronization input and on a built-in DMA request counter. Upon the synchronization event, the selected DMA request line is connected to the multiplexer channel's output. From this point on, each served DMA request, transition one to zero on the selected DMA request line, decrements the DMA request counter. In its underrun, the DMA request counter is automatically loaded with the value in the NBREQ field of the control register and the DMA request line is disconnected from the multiplexer channel's output. Thus, the number of DMA requests transferred to the multiplexer channel's output following a synchronization event is the value of the NBREQ field plus one. When the DMA Mux channel is configured in synchronous mode, its behavior is as follows. The request multiplexer input, or DMA request from the peripheral, can become active, but it will not be forwarded on the DMA Mux request multiplexer output until the synchronization signal is received. When the sync event is received, the request multiplexer connects its input and output, and all the peripheral requests will be forwarded. Each DMA request forwarded will decrement the request multiplexer counter or user-programmed value. When the counter reaches zero, the connection between the DMA controller and the peripheral is cut, waiting for a new synchronization event. For each underrun of the counter, the request multiplexer line can generate an optional event to synchronize with a second DMA Mux line. The same event can be used in some low-power scenarios to switch the system back to stop mode without CPU intervention. Synchronization mode can be used to automatically synchronize data transfers with a timer, for example, or to trigger the transfers on a peripheral event. A synchronization event or edge is detected if the state following the edge remains stable for longer than two AHB clock periods. After writing to the DMA Mux CXCR control register, synchronization events are masked during three HCLK cycles. When enabled, the multiplexer channel generates an event or a pulse when its DMA request counter is automatically reloaded with the value of the corresponding NBREQ field. The event generator is enabled by setting the EGE bit in the control register of the corresponding multiplexer channel. When the DMAX channel is in event generation mode, it generates an event or a pulse when its DMA request counter is automatically reloaded. The request counter is decremented with the execution of a DMA request. The DMA Mux channel event output can be used as a synchronization event or trigger for another channel. On its output, the DMA request generator produces DMA requests following trigger events on DMA request trigger inputs. The DMA request generator has multiple channels. DMA request trigger inputs are connected in parallel to all channels. The outputs of DMA generator channels go to inputs of the DMA request line multiplexer. Each DMA request generator channel or generator channel further in this section has an enable bit. The DMA request trigger input for generator channel X is selected through the SIG ID field of the corresponding generator channel's control register. Trigger events on a DMA request trigger input can be rising edge, falling edge, or either edge. The active edge is selected through the POL field of the corresponding generator channel's control register. When the DMA Mux is used in the DMA request generator mode, it allows performance of DMA transfers on events that are different from a peripheral DMA request such as external interrupt event, comparators output, RTC wake up, and other events refer to the STM32H7 reference manual. A programmable DMA request counter enables the configuration of the number of requests to generate on a single trigger. Upon the trigger event, the corresponding generator channel starts generating DMA requests on its output. Each served DMA request, transition 1 to 0, decrements a built-in DMA request counter. At its underrun, the DMA request counter is automatically loaded with the value in the GNBREQ field of the corresponding generator channel's control register and the generator channel stops generating DMA requests. Thus the number of DMA requests generated after the trigger event is the value in the GNBREQ field plus 1. A trigger event or edge is detected if the state following the edge remains stable for longer than two AHB clock periods. After writing to the DMAMuxRGXCR control register, trigger events are masked during three HCLK cycles. If a new DMA request trigger event occurs while the DMA request counter's value is lower than the GNBREQ field value, the trigger event overrun flag OFX is set in the status register DMAMuxRGSR of the corresponding generator channel. The overrun flag OFX is reset by setting the associated clear bit COFX in the DMAXRGCFR register of the corresponding DMA request line multiplexer channel. Setting the DMA request trigger overrun flag generates an interrupt if the DMA request trigger event's overrun interrupt enable bit OIE is set in the control register of the corresponding generator channel. The STM32H7XX integrates two instances of the DMA request router, DMAMux1 for DMA1 and DMA2 in the D2 domain and DMAMux2 for BDMA in the D3 domain. This is an example for DMAMux inputs. For a detailed list of DMAMux inputs, synchronization events and request generator triggers, please refer to the STM32H7XX reference manual. An interrupt can be generated for a synchronization event overrun in each DMA request line multiplexer channel or a trigger event overrun in each DMA request generator channel. In both cases, per channel individual interrupt enable bits are available. Please refer to these trainings linked to this peripheral for more information. STM32H7 DMA controller or DMA and STM32H7 basic DMA controller or BDMA.


Oh, hi there. Um, don't mind me, I was just on Twitter trying to look up information on the latest Nintendo Direct which is totally coming this week. Or next week, or next month, or, huh, look here's a tweet where I said like two weeks ago that I was for sure thought that a Direct would come the first week of February. Um, yeah, that tweet can go exactly where this phone is going. So, obviously, I don't know when a Nintendo Direct is coming. I hear things behind the scenes sometimes, but they don't always come to fruition. And what's interesting to me isn't even the Direct which I'm super excited about and all the potential in the world and who knows when it's coming. Uh, but what actually interests me is the hype cycle around Nintendo Directs because Nintendo is quietly over the last how many years become a master of their own design and when I say a master, I, of course, mean about how to create hype cycles around events without even talking about them. Now, we've obviously had all the hype over the years for E3 and PAX and, well, I don't know, any event, the game awards, events that we know are coming are scheduled and that Nintendo typically shows up to. But we also know every single year, we're gonna have two, we're gonna have three, we're gonna have four, five, six, a whole bunch of Nintendo Directs, whether they're individual game Directs like for the upcoming release of Animal Crossing New Leap or if it's just a general Direct, which is what most of the hype exists for. Well, that and sort of would get pretty hyped for those Nindee ones as well. But here's the thing, we get hyped over the idea a Direct is even coming. It doesn't matter who says it, it doesn't matter if I say it, a random person on Twitter, a comment on a video that just gets a lot of likes, it just, everyone wants the new Direct. And to me, it's interesting to see that how Nintendo Directs and Nindies and whatever you want to call all the various events, digital events that Nintendo puts out there, how it's kind of come a culture icon on its own. I don't know that Nintendo could ever stop making Nintendo Directs because of how iconic the hype cycle for them has become. Every single day, every single week, every single month, there is new hype and new rumors surrounding Nintendo Directs. You have YouTuber after YouTuber reporting out videos, talking about when's the next Direct coming is this coming, the last rumor, there's two Directs coming, General Direct and one for Animal Crossing New Leaf, and all the Direct will be this week, all the Direct will be next week, all it'll have the Switch Pro, it'll have Breath of the Wild 2, all we don't actually know anything at all about when these things are coming, but everyone and their mother wants to take a stab at it. And it's interesting because I think we as gamers like to be excited. See, I think Nintendo Directs are almost sort of a savior, as it were, of video game culture. Now, let me explain what that means. That's a pretty loaded statement. Video game culture, I don't think needs to be saved on the whole, but there is a lot of negativity in video game reporting and just video game culture on the whole. Sure, there's positive news. I think the reaction to the Division II's announce expansion pack today has been rather positive, but there's a lot of negativity as well, both around the people that cover video games and the people who play them and obviously the people who create them. Obviously, there's been the negativity around the Pokemon Leaker and Nintendo going after them and outing the whole website, but beyond that, there's just a lot of negativity in the gaming community. Some of it's justified. Admittedly, me saying things like Animal Crossing has microtransactions without the caveat that it could have. And here's why I think that. It creates a negative impression and obviously as negativity. And I'm not going to pretend that I avoid negative statements and negative type videos on my channel, but what gets lost in all of it is that the hype around Nintendo Directs is always a positive thing in the gaming community, not just Nintendo fans. There's Microsoft and Sony fans and PC gamers looking forward to Nintendo Directs as well because we all want to see what's Nintendo going to do. Sometimes out of more big curiosity or just because we really want to know what's next for a platform we all own and enjoy. Now, there's something like 60% of Switch owners also own a PlayStation 4. So when I say it's something that everyone seems to look forward to, I do mean everyone, especially since the Switch came out. And it leaves me wondering and questioning a lot of things in life, but it doesn't make me question what is so great about being a gamer? And it sees positive moments of hype for something that we don't even know if it's worth being hyped about because we don't know what's going to be announced. That excites me the most. And it used to be that gaming Christmas at E3 was the one time per year that we could all as a gaming community come together and get hype. But as E3 has become less relevant over the years, starting with Nintendo Directs and PlayStation events and Xbox events and PSX and whatever, E3 is still pretty hype, but not quite as hype as it once was. We've got to this point where everyone is following Nintendo's example and now we get the PlayStation experience stuff or the Xbox streams. I forget what they call those little Xbox shows. Sorry, I probably should have looked it up before I started this video. Reality is everyone's following Nintendo's example and they're doing this because Nintendo has created positive momentum in the video game space. Even during the Wii U and 3DS era where Nintendo was kind of seeing some lows as a company, they were able to generate hype even still for these unknown mystery events. Ooh, is the next system going to be available? Ooh, are we going to find out more about Zelda Wii U that was announced in 2014? What's happening next at Nintendo? Excites gamers everywhere. And it's starting to excite people for the PlayStation stuff, the Microsoft stuff, and anyone else who decides to use this format as well. And as much as it's cool to see that Limited Run Games is going to have their own live press conference at E3, which is really, really neat to see a company try to save E3 as they claim. That's kind of their mantra this year. It's also nice to see that there's positive momentum in other parts of the year as well. Positive electricity around gaming. And Nintendo is largely to thanks for that and Nintendo Direct Hype is largely to thanks for that. So yes, now to the end of time, you're going to see YouTube video after YouTube video, tweet storm after tweet storm. Everyone trying to predict when the next Direct's going to come. You're going to see negative reactions to when Direct's hit, positive reactions, all that stuff over what's announced in them. But one thing we can all agree on as a gaming community is it's really exciting to think about what's next. And I think we've always had these debates about what's next, you know, hey, what's happening for Nintendo after the Switch? What's the Xbox Series X going to be like? What's the PlayStation 5, you know, consumer version going to look like? Not the one that we've seen leaked now for developers. What's the consumer version going to look like? How powerful is it going to be? What are the games going to be like this, that, and the other thing? It's always exciting to think about the future of gaming. And that's what Nintendo Direct's do every single year. Multiple times a year. Any possible month one can be dropped. And it creates all this excitement over what the future of gaming is, well, for this thing right now, or for whatever Nintendo does next. And that is such a positive momentum push for gaming because as I said, there is a lot of negativity. We all are aware of the negativity in gaming, the Gamergate stuff in the past. And just everything surrounding video games always seems to have this negative connotation.  It's nice to have a positive reminder that there is something good and fresh to look forward to to help us push gaming in a forward moving pattern. And Nintendo Direct's do that. So what's the point of this video? I guess just to celebrate Nintendo and the Nintendo Direct and that they even do it and what Direct's have meant for this industry of negativity surrounding everything for most of the year until we get to an E3 to now there's kind of a positive conversation point every month. When are we going to get the next Direct? What's going to be in that Direct? What games are going to be announced? What games are not going to be announced? Are they going to be game delays? Are we going to see the third party games? What's the next big indie title coming to Switch? Is Microsoft going to bring over more of their indie style games over? Oriental Blind Forest is coming. Are we going to get the sequel?  So yeah, I don't know when the next Nintendo Direct is. Maybe it's tomorrow. Maybe it's Thursday. Maybe it's next week. Maybe it's next month. I have no idea. Maybe we don't even get anything until E3. But what I guarantee you there will be are many videos, many tweets, and many hype around whatever and whenever the next Nintendo Direct is. Now what I want you guys to do is go down to the comments below and let me know what about Nintendo Directs and the example they are setting for the industry. And how Sony and Microsoft seem to be following suit. Let me know down in the comments below what you think Nintendo Directs mean for the video game industry. What do you think is particularly awesome about the fact we get Nintendo Directs or the hype and the build-ups in Nintendo Directs? Do you think it's too much? Obviously some people think over positivity is an issue. I don't really think over positivity is an issue. To be honest, there's so much negativity in the world. Let's get overly positive about something we don't know about because why not? It's a lot better than being negative all the time. And yeah, if you enjoyed this video and you want some more hypothetical discussion videos like this, let me know down in the comments below as well. It's kind of a different video. It's not news. It's more of a kind of a think piece, right? What do Nintendo Directs mean for the video game industry? I want you guys to answer that question down below. Now, I am Nathaniel Robledance from Nintendo Prime. I want to thank you guys so much for tuning into this video. If you enjoyed it, drop a like, comment below. Obviously, subscribe for more content. Hit that bell icon so you get notifications for all the live streams or you're supposed to get notifications for the live streams in every video. And obviously, enjoy the next game you play on Switch or on PlayStation or on Xbox or PC or heck. If you like gaming on your phone, which I guess I dropped my phone in the trash. So I guess I'm done doing that. You know, let me know. In fact, let's end it with this. What's also your favorite game coming out this year that we're currently aware of? All right, folks. Thank you so much. And I'll catch you in the next video.


One, welcome to our session today. It's a how-to product development of a browser extension. I'm Emily Pace. I'm the principal linguist at Expert System USA, and I'm one of the co-organizers of Linguistics Career Launch. I will go ahead and turn it over to Andrew Nelson from Data People, who is here today to tell us about this project of his, something he worked on and built while working as an industry linguist. Thanks, Emily. Hi, everyone. Yeah, I'm Andrew. I'm a linguist at a company called Data People, and we look at job descriptions, try to make them work there. And as a sort of a side project over the last eight months or so, I've been working on a product called Redefine. And so I'm going to share my screen and talk a little bit about my work on Redefine. Redefine is a browser extension, and it's also actually a mobile application as well that automatically simplifies complex language when you browse the internet. It helps you read faster, understand more, and stay engaged in what you're reading. It works by reading the page data of any website that you go to and replacing complex words and phrases with simpler alternatives. When Redefine simplifies language, it shows you an underline on the new word or phrase and a tool tip when you hover over the new phrasing to show you the original word or phrase. So in this example here, the word ameliorate has been simplified to help. And so as you're reading along, it just says that can be done to help such a situation instead of that can be done to ameliorate such a situation. And that's much easier to read.  So my motivation behind building Redefine. So in October, 2020, I was scrolling on LinkedIn and I saw a trend of people using jargon and complex language. Things like synergies or leverage or utilize, all these words are more complex than they needed to be. So as I read posts, I noticed that I internally attempt to reword or rephrase these LinkedIn posts. And in many cases, in lots of different contexts, writers don't use a writing aid. So like Grammarly or pro-writing aid. So like on emails, maybe they use a writing aid, maybe they don't. All sorts of different circumstances where writers don't use some sort of writing aid. And this leaves the reader with complex language. And that takes longer to read, can cause misunderstandings and make the reader lose interest in what they're reading. So yeah, that's some of the motivation. It was made for all kinds of readers but it's particularly useful for certain kinds of readers. So business professionals, students, non-native English speakers and people with reading disabilities. We found that these four groups really like redefine for different reasons but they can find use with redefine to varying degrees. So I decided to see if, so that was sort of like my motivation, what was going on in my head. As I was thinking about, you know, LinkedIn and all these like places where you encounter jargon of complex language. So I decided to see if I could build a product that solved this problem across the internet. So I built the minimum viable product in late October of 2020. It had a very simple hard-coded dictionary. So that means that the dictionary was like in the code and it was just 20 words. It only replaced words and it broke a lot of websites. So as I continued working on it, I actually got some interest in it on some Facebook and Reddit posts that I made. Got some interest in it and people thought that it was an interesting idea. So I decided to continue working on it, to continue building it and sort of scaling it to be a little more useful beyond just 20 words that are getting replaced. So, but I quickly realized that if you want to update, like if I wanted to update the redefined dictionary, so instead of going from 20 words to like 200 words or 1,000 words, I needed to have that dictionary stored outside of the extension. So otherwise the user would have to continue, like they'd have to continually update their extension and that's a really bad use case. Like on your iPhones, you don't continually, like you don't have to continually update your app to get like new Facebook posts or things like that. It just like comes in from the API and that's called a client server system. So I had to learn about that. I had to like figure that out, figure out what is a client server system? What's, you know, how do I make this into a client? What's an API? Things like that. And I found Firebase and that's really, Firebase is really easy to set up for mobile apps and extensions. And so, and it allows you to store a database and build an API, which are both things that I needed to do to build this sort of client server system. This is what Firestore looks like. It's, well, this is what Firebase looks like and this is the actual database, the Firestore database. And you can see some of the words that we simplify here. It scrolls a lot more than that. But yeah, we've got, I think we've got like three or 4,000 words and phrases that we simplify now. But this is sort of like the front end experience of Firestore. And then I can use Firebase to actually like do stuff with this. So I've had to solve a number of other problems. So that was like one major problem I had to figure out. Some of them were minor. Some of them were really major. Like for example, Redefine originally sent each note of a website to the server to get redefined. And this caused a lot of like some websites would send hundreds of API requests per website. And that's a very bad user case. So as an example, that's like, so basically what happens with an API request is the client throws a football to the server. The server edits the football and sends it back. In this circumstance, the client was sending hundreds of footballs. It was throwing hundreds of footballs. And so I had to fix that. I had to figure out how to fix that. And I did that by only sending one bigger football. And so now the client makes all of the simplifications at the same time. So talks a little bit about some of the problems that I encountered as I was building Redefine. But what does Redefine actually simplify? I showed earlier the Firestore, a little bit of the Firestore. And you might have noticed, but it was doing like one word replacements, right? When I first thought of Redefine, I pictured it as a product that simplifies all kinds of language. So words, phrases, sentences, maybe even paragraphs. Complex language is not just a lex problem, right? It's not just a word level problem. It's also syntactic. So phrase or sentence level, but it's also even a discourse problem. So that's like at the paragraph level, like there's still like complex language at the paragraph level. And unfortunately, I've had some problems actually doing replacements as some technical problems with Regex and things like that with actually doing replacements, given my current system. So currently most of our replacements are single word replacements, so lexical replacements, but we do some two to three word replacements. The larger that like multi-word phrase dictionary gets, the slower Redefine gets. So I'm actually rewriting the API right now to use Python, a specific library in Python, which is way faster than the current system. So then after I'm finished with that, I'll continue working on the multi-phrase or multi-word phrase dictionary. So let's get into some of the features. As I built Redefine, I began to realize the potential and danger of an app that can reword the internet. So I think one other use case that I recently thought about was like a parental like censoring feature or something like that, which could be useful, I think. I asked for some product feedback in a few places like Reddit, Facebook groups, and people began to give some really good feature requests. So I built some of them and some of them are more long-term product road map. But yeah, I'll get into what's currently available. And as a preface, there are three versions of Redefine. So we've got the basic version, which works right out the gate. As soon as you install it, it starts working. You've got the free subscription, which works after you log in.  You just like send me an email and I'll get you set up on it. And here are the features. So we've got the basic version where Redefine automatically replaces thousands of words and phrases. You've got the free version where you get the ability to have your own personal Redefine dictionary.  That may not be in the Redefine dictionary, like the public Redefine dictionary. You have the ability to enable or disable websites, which you can do actually with extensions, but it makes it more like local, easier to use actually within the UI of the extension. You get learning and reading mode. And learning and reading mode, I'll demo this in a little bit, but learning and reading mode are, so by default, Redefine does the reading mode. So it automatically tries to help you read better. But learning mode is very useful for some people. It does not reword the website, but it provides tooltips and underlines on actual complicated words. So instead of actually rewording, it keeps the words and then just flags the words that are complicated and you can hover over them to see simpler alternatives. And I'll show what I mean here in a minute. And you get access to support. So you can get help, you can submit support tickets, things like that. And on the paid version, you get Redefine dialects. So it will replace like UK words with US words. And right now it's just UK to US and US to UK, but in the future, we want to expand this to like more granular dialects. So the South versus Northern dialects or other sorts of dialects. You get Redefine on PDFs. So Redefine will redefine PDFs for you. And there are add-ons. So you get dictionaries for business, medical, science and law. So without further ado, I'll actually give a demo of Redefine. So if we look at this article here on nature.com, the title says, can physical activity ameliorate immunosin essence and thereby reduce age-related multimorbidity?  And I was like, this is unnecessarily worthy. So I decided, what would Redefine look like on this page? So we'll go ahead and refresh this page and see Redefine in action. So now Redefine has changed it to read, can physical activity help deterioration and thereby lower age-related multimorbidity? And instead of saying ameliorate, it now says help. Instead of saying immunosin essence, it now says deterioration. And we can see the learning mode by clicking here. And now we see the actual text unaltered, except now it shows little tooltips. And so we can see what these actual words mean here. Or like we can see like the simpler alternatives by hovering over these words. So this is what the extension looks like and you can manage your words here. Like I can create a new word here if I want a test and it will give little alternatives here. You can switch your preferred dialects. You can add or you can manage your add-ons here. You can switch to reading mode, learning mode and get support. So that's what Redefine looks like and that's how it works. Still working on it, it's almost, I think I work on it like maybe 10 hours a week still, but the future of Redefine is as with most language tech problems, a machine learning problem. So there's actually a fair amount of research both in academics and in an industry for lexical simplification and syntactic simplification. And I'm currently working on figuring out what's the best solution here. Ideally it will allow the reader to adjust how aggressively Redefine simplifies in the automated way. So yeah, things that I've learned. I've learned about client-server architecture, like what an API is and how to make one. Like how to make a client-server interaction work. I've learned about front-end web development, JavaScript, HTML, CSS, WordPress, PHP, learned about backend and database developments. Including Firebase Cloud Functions, Firestore and Google authentication. Learned about mobile app development, including Swift and Kotlin. And I've learned about the simplification NLP task. That's a very big task in the world of NLP and some of the relevant things that go into that are BERT, Transformers, Docker, Python, Kubernetes, GCP, which is Google Cloud Platform and language model deployment. So just a quick note, before we get the questions coming, I, as a linguist, I really appreciate the nuance that certain words have over others, right? So I appreciate a well-crafted article or a well-crafted note. But sometimes those well-crafted nuances can impact the audience, that can impact the reader understanding. And that's obviously not the intent of the author, but the goal behind Redefine is to sort of relieve or help those sorts of situations. And so, yeah, that's redefine. I'd love to open it up to any questions or... Thank you so much, Andrew. We actually already have a few questions in the chat, which I'm happy to read. So can you talk a little bit more for our audience who might not be familiar with APIs? What's an API? And when you were talking about that football, what's the football? Yeah, yeah, so an API is basically how computers talk to each other. So it's when I text to you, like say I wanna text you. I have to write out a text and then send that to you. That's basically what's happening. And say, actually, say I wanna figure out, say I need to ask you a question and I need to get data from you, right? I don't have that data on hand, but you do have that data. So the server, the client server thing that I was talking about earlier, the server is what does processing. That's what knows the answer, right? The client is the one that's asking the questions. So the client in this case is redefine. It has a bunch of data about the page that you're on and the text that it sends to the server is like, here's the data and here's your authentication information. Here's all this data. And then the server receives that data and begins to process. It begins to like make sense of the data in terms of authentication, in terms of the actual data that it received, like the text data, the page data that it gets. Yeah, an API is how they connect to each other and talk to each other. And you'll typically hear like an endpoint. So an endpoint is a URL that you contact or that you send data to and that's the server, like that's how you connect to the server and then that endpoint will process that text and send it back to the requester. Yeah, I hope that made sense. We have another question here about what the process of building the dictionary was like. So what form was it in and where and did you build that manually? Yeah, the vast majority was built manually. Like I said, there are a few different dictionaries. So we've got the one-to-one dictionary then we've also got a multi-word dictionary. And so the one-to-one dictionary was pretty simple. I found a bunch of different resources about simpler alternative dictionaries and things like that. And one of the challenges is foreseeing instances where a word may not work in another context. So replacing a word like ameliorate gets changed to help. So, but is every single instance of ameliorate easily replaceable with help? Like is that always the case? Cause it's a really bad user experience when a user sees a replacement that's not, that doesn't work in context. So building out, so I've done a lot of testing on those different words, like just a lot of thinking about like, okay, different circumstances where it might not work. And that works, that happens a lot with like phrasal verbs and things like that. So building out the dictionary was not super challenging but I used a lot of different resources to build it. And on the note of resources, we have a couple of similar questions. One about whether you wrote the program in Python and then what your background in tech was like, you know? So what skills, what coding skills did you come in with to build this and what did you have to learn along the way? Yeah, so the first question about Python. So no, it's actually all in JavaScript. So both the front end and the backend are in JavaScript. So the Google, so the Firebase Cloud Functions that I was referring to, that's what I refer to as the server, it's technically called serverless but it's the backend. So that's what it contacts. And then the Firebase Functions are what process the text. That is all in JavaScript. So that's a Node.js server. And yeah, it's all in JavaScript. Actually, it's not a great system currently. As I said, there are a lot of problems with it. I'm experiencing this problem called catastrophic backtracking with Regex where you've got a very large Regex and a very large string and that can cause huge time delays. And so right now I'm working on moving it into Python and I'm going to use a Dockerized Python app on Google Cloud Platform to, yeah, I actually have tested it and it's about 15 times faster. So it's great. And then my background in tech, I work at a company called Data People and we do, I basically work on the language guidance that we provide, but I've done a number of internal tools like developing internal tools like a linguist app and a few Chrome extensions for Data People. So yeah, we've got some experience but redefined has really, I guess, redefined how much I know about tech and how things work all together. Like I didn't know anything about what an API was or Firebase or anything like that before I started working on redefined so. How did you figure out what tools you needed to solve what problems? We always get a lot of questions about like, where do I learn about things? Yeah, yeah, so the very first, I think the thing is, I think you have to start with like a goal. So my goal at the beginning was, okay, I need an MVP, I need to get something working where it just can replace the text in any website that I go to. How can I replace text? So that's like first step. Googling a bunch of like, how do I inject a content script to replace text and things like that? And then you get to the next problem and it's like, okay, I've got this working thing and I want to be able to do a thousand words, not 20 words and I can't stick these thousand words in the extension. Like here's the problem. I can't, I need to be able to update the dictionary. Well, how do I solve that? That's required me to think about like, okay, well, how do other apps do that? How do other extensions and things like that do that? Well, they use an API. They use like a client server architecture. Yeah, I think one step at a time. I think that's really been sort of my theme here at like working on this product has been like one step at a time. For example, another case or another like thing that I solved during my time at Redefine was building the landing page, which am I still sharing? Yeah, show. Which, okay, so I'm not a designer by any means. So this is still like a work in progress by a lot, right? So it's not pretty, but building it has been like, I mean, I built it all and like I figured out how PHP websites work and things like that. So yeah, I think one step at a time, that's sort of the advice that I would give about where do you start? Well, you start with a need and then how do you solve that need? Well, what's the first step? What's the minimum viable product? What is in my case, I wanna simplify language for people. How do we do that? Well, an extension is definitely the best way in terms of on the internet. I'm not really sure about other situations like reading on a Kindle, I'm not sure how that would work, but reading on Kindle on Google Chrome, that would work. So yeah. So all these little steps to get there are those steps that you have been doing all on your own or do you have collaborators who you're working with? Yeah, most, yeah. In terms of tech, it's all been me. In terms of some of the marketing has been done by some other people, or like I have a co-founder that's helping me and yeah. So some of it has been other people, but most of the tech has been me. And same with the dictionary development. I do actually, I do want to, in the future, I want to sort of open that up to like, so that, and I think one thing that I wanna do is build like a sort of a rules-based system that maybe other linguists can contribute to or something like that. And I think that would be really, I mean, very powerful to scale the dictionary, so. And we just got another question in the chat about if you've thought about adding a dark, a dark-teamed reading mode to increase accessibility options. So an idea. Yeah, so some of those things. So that's, I've heard about that or I've had a request for that before as well as like text resizing options and things like that. Like how big is the text, that kind of thing. That's difficult to modulate on an internet-wide level. It's difficult because so many different websites are so different from each other. Yeah, I don't know. It's a challenge. Does anybody wanna chime in with other questions? Either put them in the chat or turn on your video and audio. Are there questions that we have for Andrew? I would ask a question for you while others are thinking about what questions they might have, which is, you know, so this is something you've been working on as a side project while you've been employed full-time. You know, how do you balance that? And for our attendees who are still students, you know, they might be trying to balance doing a project like this with their schoolwork. So how did you handle that? Yeah, so I think it's really important to strike that balance to not get burnt out. But I do think that it was, for me, it was sort of born out of this desire, A, to solve this problem and B, to expand my resume and to learn all this stuff that I didn't know previously. It's been a huge learning opportunity to me. And each little piece, like I said, with, like right now, I'm working on this, like I said, I'm working on this Python, this Dockerized Python container that will serve as the new API endpoint or serve as the new server. I'm learning right now how to, how do I actually deploy that? How do I use, or in other cases, like how do I serve or deploy a language model? And that's like a learning opportunity in my mind. And it will be more useful, I think, than just here in this moment for redefine, so. And we have a new question, which I think you touched on a little bit before, is there or will there be an option for users to share their custom word replacement list, maybe even for interesting or funny things beyond the original purpose for better or for worse? Yeah, yeah. So I think, yeah, I have to think, I have to think through more about what the product would look like then, like how I would, how I would go about having multiple levels of things. I've been thinking about like switching. So right now, right, you've got the two versions of, or like sort of two main dictionaries. You've got other, we have other dictionaries, but we've got this concept of redefine like public dictionaries. So those are like the ones that redefine will do for everyone. But then you've got your own personal dictionary. And I've been thinking about making those like different colors or like, I don't know, some sort of system like that. And then I think the add-ons, we could create new add-ons that could be user created. And so maybe that's the approach there. I have to think more about the, but I would love, honestly, I would love to collaborate. And if anyone is interested in, or has like thoughts about it, I'd totally be interested in working with anyone to expand that sort of like product thinking. So. We've got another question here. How would you advise someone to get over that hump of learning something completely new, especially for a language that does not have much technical or coding background? Yeah, so I think, so going into my current job at Data People, I didn't know a ton of, I guess I had started a, I did start a minor a long time ago in computer sciences, but I think the main thing that I would suggest is starting small and doing like one small project and then trying to expand on that project and to like make it better, make it faster, make it cleaner, that kind of thing. I think a good example, like for me, working on Chrome extensions has been very, very helpful because I've learned JavaScript, I've learned HTML, I've learned how websites work, things like that. So, but it started out very, very simple. Like way more simple, like instead of replacing text in a website, I just want to add something to the top of a website. Like how can I add something to the top of this website? And that's, I think that's step number one or even just creating your own website, creating like your own personal website, I think could be a very, very useful. And also, productive, like, I mean, you could put that on job applications, like here's my website, like here's what, some of the things that I've worked on and I think that can be very interesting to future employers. Any other questions that people want to add in here as we get to the end of our time? At what point would you put, this is a great question, at what point would you put a project like this on Resume or LinkedIn? Yeah, so I actually, I put it on my Resume, I didn't put it, I don't have it on my LinkedIn, but in it, I guess it's on my portfolio website too. I put it on there after I actually created a company out of it, so I'm the founder of Redefine, but it's like not, it's like a, it's still very, very small and early, so I'm not like making any money out of it or anything like that. But so like, I would do it as soon as you're like proud enough of it that, like to show off to other people. Like at this point, I'm proud enough of it to like show to other people. At the point where it was where it was replacing 20 words and it broke a ton of websites, and it still like does some weird things on some websites. So I'm still like working on it, but I wouldn't have shown it at that point. So I think as soon as you're like confident enough that like, oh, like somebody could actually find use out of this, then I think it could, I think it belongs on your portfolio or LinkedIn at that point, so. Would you have been comfortable in that early phase mentioning it as part of an interview process, even if it wasn't on your resume yet? Yeah, I think mentioning it, I think that can be very useful just in terms of showing that you're a curious person and that you will push yourself, that you'll like teach yourself, that you'll learn yourself, that you'll like work to figure out a problem that you haven't like understood before, so. I think that's, I would definitely echo that. I think that's definitely true. Employers like to see curious people who want to solve problems. All right, well, I think we will, we can go ahead and wrap up here unless anybody else wants to chime in with something. So thank you so much Andrew for coming today to tell us about your work and your experience. I think this is the sort of side project is so encouraging for people to hear about because they are getting the advice in other venues. If you should have a side project and you've been generous enough today to share with us how you can have a side project. So thank you so much and everyone have an excellent day. Thank you.


All right, I want to thank everyone who's joining us. Welcome to today's CNCF webinar, the what's and why's of distributed tracing. I am Libby Schultz and I'll be moderating today's webinar. We'd like to welcome our presenter today, Dave McAllister, senior technical evangelist at Splunk. A couple of housekeeping items before we get started. During the webinar, you're not able to talk as an attendee. There's a Q&A box at the bottom of your screen. Please feel free to drop your questions in there and we'll get to as many as we can at the end. Not the chat, be sure you're dropping it in the Q&A box. This is an official webinar of the CNCF and as such a subject to the CNCF code of conduct. Please do not add anything to the chat or questions that would be in violation of that code of conduct. Basically, please be respectful of all of your fellow participants and presenters. Please also note that the recording and slides will be posted later today to the CNCF webinar page at www.cncf.io slash webinars. And with that, I will hand it over to Dave to kick off today's presentation. Take it away Dave. Thanks. Appreciate it. Hi everyone. I am Dave McAllister. I work for Splunk as a technical evangelist here. And at Splunk, we have this saying that every person is made up of a million points of data. So let me share just three real quick ones with you for here. I'm owned by three cats. So I'm very good at being ignored. I spent 10 years as a soccer ref. So I'm used to people disagreeing with me. In fact, I could pretty much guarantee that for any given moment, at least half of the players on the field would disagree with any call I made. And finally, I'm married. So I have a witness that I don't read minds. Please make use of the Q&A box that was just pointed out to you so that we can get your questions answered as well. So I'm going to be talking about tracing, but I'm going to start a little bit by talking about this concept of observability that has come into play recently here. And it's real obvious that data is this driving factor for observability. And part of that you'll find that there are lots of pieces. There are the three classes of data that we talk about metrics, traces and logs. But imagine, for instance, if you never got all the data, or you missed ephemeral data that was decided here, or your data showed you something you couldn't drill into, or you only saw the good stuff, or the bad stuff. So why does that really important? Well, part of it is, is that our world is changing, our application space is changing. And we're now are into a microscope style of architectures, where services are are independent, usually coupled loosely coupled, and can expand or contract as needed inside of this. And so while certain things have become easier, so CI CD has become easier in some ways. Simple testing has become easier. Testing, on the other hand, we can start getting the synthetics and start looking even at passive monitoring the room. But nonetheless, we now have a lot of moving parts. And when we throw this also into a cloud, we also can throw this into a hybrid cloud where part of it lives inside a data existing data center, as well as into a public cloud. Life becomes a little challenging. And that's part of what happens when we deal with this. So each of these pieces coming into the front end from your HPP may look at the cart service may look at all of these places. And so each of these pieces get touched in each transaction. Now the nice thing is that our tools tend to be smart enough to be able to map the transactions for us. But when we get into tracing, we start looking at what that means inside of here. So that simple little step through that I just did, for instance, the front end came in. Overall, you can call the environment took about one and three quarter seconds of which roughly slightly over one second was in the checkout service, which then breaks down into each of these pieces. And this is where tracing really excels showing us what's happening inside of the application on a service by service basis for a request of interest. And when we start looking into this a little bit more, we can start looking at that the transaction shows us what's happening in the microservice, which then considering the functionality within that microservice, as well as the expansion into the other microservices. So think of these as the trace is all of it grouped together, and the span is each individual portion, or any particular portion that we choose to measure. So those are the reasons in here, and that goes across time. These are all time series based. So our same functionality, the same application we're looking at. We see that the CPU is now pegged out at 100% and it's been that way for over five minutes. And that starts leading to some questions that are necessary to understand the CPU at 100% may not necessarily mean that there is something wrong, there may not be an error, but it can be a delay, it can be communications problems. And just as we do notice that at the same point in time, we had a new code push the front end version changed microservices services change all the time. We mean companies where they push 100 different versions of different microservices on a daily basis, and I suspect some of you all may even be exceeding those limits for here. You can see that we've seen an event that that's caused potential happening. And what the actual functionality is showing is that we've actually seen a service, not available showing up as the far end of this thing, HTTP 503 error codes that are showing up in the shipping service. So when we start tracing this back, and this is what tracing is extremely good at is we'll be able to go from the error structure, all the way back to the underlying causes that happened there. In this case, something's wrong with our latest push auto remediation remediate by rolling back to a formerly known good version, and then start digging into the underlying problem. What this really starts leading to is that each of these pieces in turn get impacted, and they will all show up in your overall environment. So, shorthand observability is not the Microsoft. It's the clarity of the slide and the microscope is what the data can tell you in our old world with with black box monitoring or even far enough back where do we go into the data center and make sure all the little servers had their lights blinking at us. This is now we need to get more information and more details under that. And to do that, we need to be able to collect our data collection isn't also beginning to change a little bit because of the nature of our underlying structures here. We now need standards based agents. We can't live with with data that's coming in from a prior to your basis or being going out in a proprietary basis. We need cloud integration so that it understands how to deal with the public clouds, the private clouds, even into our legacy centers inside of here. We need the code to be auto instrumented. There's been a huge amount of discussion about whether you should should hand hard code everything into an application. But I think, again, think about how often services can be rolled up across this incredibly large environment now. And if every time we changed it we had to rebuild manual instrumentation within our code base, we'd be able to have a bit of a headache over time. Likewise, we want to support all the developer frameworks that make sense. We want any code at any time. And honestly, as we expand the scale we don't want to have any limits on how we can slice and dice this data to find out what we're interested in. Now, we've seen a lot of this metrics is a pretty well understood issue logs have been around for forever. If you give far enough back into the history of computing you'll run into a concept called Wolf fencing, which originally led to the original concepts of applications right rates inside. But when we look at this it really started with open tracing another CNC F project here open tracing defined how we could make use of tracing and the information. It's the second product that came out from Google in particular open census came up and the two were in the same area but not quite the same. And then fortunately, those two groups got together, I did create a new project open to lemon tree. And this is a both open tracing and open census, including backward compatibility across so that you can actually make use of your existing environments as well as what's coming out next with open telemetry. So think about this data coming in is really about the telemetry and the telemetry verticals are quite often. In many places, I mentioned for instance these three classes of data sometimes called the three pillars of data here tracing metrics and logs. But we now want those for every language of interest. We want the canonical implementations also for every language of interest. We want the data structure to be set up so that it is standard across all these environments and can be pushed in multiple methods inside of here. And then the formats of how things come together. So the wire formats the trace contacts, the data structures themselves are all standard so we can interrupt between them. And these are thinking of these the layers of what's going on of the activity for each of the verticals. Each of these verticals may have a different approach, but each of these verticals must have each of these layers. Each of these layers expand out rather large so for each language. It's easy to say there's too many languages to do this but if we look at this and say we're going to do the major languages and the major data structures, that's probably a great place to start, because we're also open. If you are interested in doing a particular one, it's available to do that as well. The nice thing is open telemetry is actually addressing these categories and the layers and are working to cross all of those tracing is definitely the most advanced. It started with existing tracing functionality from open tracing and open telemetry. Open telemetry has the most advancement. Betricks is a close follower to that and logs will get a little bit more into later are becoming the next direction. So open telemetry not only supports all of the telemetry verticals and things, but it also supports all three classes in one. You know, open telemetry is the second most active project in CNCF today, only by behind communities itself. So let's get into a little bit about the heart of what we're talking about here. And that's, so what do you want to trace tracing incredibly powerful, but it does take a certain amount of effort on your to make it useful to you. When we start looking at this, we'd start by saying what problems are we trying to solve. And by the way, this is a very small subset of potential answers inside of here. In the example I showed earlier, we're trying to solve a performance issue, things running slow, or we're trying to resolve an error issue. Why am I seeing errors being reported from a service. And when we start looking at this, we want to make sure that we are responding as quickly as possible at the same point in time. Meantime to resolution the meantime to detection need to be as quick as possible. Errors need to be solved as soon as possible. A recent Google study they updated for 2020 shows that roughly 3.6 seconds will cause a wait time will cause a bounce when sitting there on your site. So think about it this way we're an instant gratification society, and we need to make sure that we're getting resolution as fast as possible. The nice thing is about tracing works with the metrics and the logs. So they provide multiple sets of contacts in here. And the more data you can throw at this, the better your answers and the faster you're going to resolve the issues. However, when we look at the current methods that have prevailed beforehand, what we found was that there were some gaps that showed up here. And again, I'm sure that you can add to the gaps yourself and have additional But it was difficult to say what was observed to what is currently working inside of here. And we were having to collect data from different formats. So the metric format would be coming in and one, one wire or one format model, while the traces would be coming in and it's a different one, and the logs would coming in as you get another different one. So if you didn't have those you may have may think that you're, you're fine they have no gaps, but you may need to start looking at new things, you're developing new services to developing new code, and there's new functionality that's coming into play here. So when we start looking at those various things here, we can quickly arrive to the question that says, where am I, what problem I'm trying to solve. What is for I've got gaps, or I just wanted to get to the latest functions and features here. Next question is to start looking at what teams going to make use of tracing, not all teams necessarily make use of tracing in the same ways here. Tracing can be heavily used in dev environments for instance, tracing can be a benefit to the sre environments, tracing may not be as important to your network management, but it's still useful inside of here. The next part of that is, okay, so teams components and make use of this, who's available to do this work. Again, it's been made as simple as possible, and we'll look at auto instrumentation, but we really need to be able to make this as short as possible in getting started enough and running. And then, what's our short term goal, getting control of our system or understanding what's a long term goal, continuing to prove the customer experience as an exception. If you are already using it, are people making use of this, and if they're not, why aren't they doing this. And then finally, sort of why tracing now, which we kind of answered in the first place, which is our applications are changing, the nature of our infrastructure is changing, our environments are changing, and our customers expectations are all changing. So I want to step a little bit into the architecture of open telemetry itself. And my apologies, I've not updated this for the absolute latest set of meetings. And I'm sure we're going to hear a lot more about about what's going on here at open telemetry community day and cube con coming up next week. Breaking it down. The open telemetry environment has a set of components here is you can see them listed here and they are specifications. How do we deal with this functionality, the collector, where are we getting the information. How's it coming into here, client libraries that are coming into here. And then we also are incubating for traces and metrics were incubating or beta for traces and metrics incubating for logging, but auto instrumentation pieces are beginning to evolve. And in fact, already there with auto instrumentation. So when we start looking at these pieces here, it's easy to start the break down. So let's take a look. This is a open telemetry reference architecture here. Asian can on a host talk to a collector, hotel collector or the agent that agent can send information, either traces or metrics and traces off to the back ends of choice, whatever they are. It's agnostic. It doesn't really care what you're talking to on the back end. So the hotel library that can be part of your application can automatically talk to the agent to send the same patient for here. The hotel collector as direct can bring all that information and talk back to those various pieces. So the applications can now be bringing the data in from multiple sources and multiple places to multiple endpoints. And so this is a very powerful architecture. This is not a one size fits everybody. This is size to fit you correctly. This is important because tracing is fairly data intensive. There's a lot of information is flowing through your tracing environments, and you really need to keep as much of it as you possibly can. So you can answer questions that you didn't even think were going to be questions when you started for this. So the tracing side, which is the most advanced is W3C trace context or be inside of that is concept is to get the context of what's going on here the tracer functionality here. That is a series of calls the spans make up the trace. A trace is a series of spans, whether it's a single span or multiple spans is is part of the underlying structure here. The span can tell us additional pieces of information, what kind of communication is going on, what its attributes are it's key value pairs it's tags or it's metadata here events that have happened earlier on in the example. For instance, I showed that a service deployed, that would be an event that happened inside of here, and then links that we can drill off to here. We can also look at sampling functionality, we can look at span functionality, and we can export to the data anywhere into any functional wire format that we want via the open tracing protocol itself. Yeager zip can permit this. It doesn't matter. Those are the advantages that we started looking when we start bringing this tracing information into play here. There is something that's very important to understand when we start really getting into this, and that there is this thing called conventions semantic conventions here. In open telemetry spans can be created as many as places as you want to. And sometimes it can be a little bit of an overload of the amount of granularity that happens, but that's an issue that you need to undertake understand what's providing the best set of information for you here. We're looking at some well, well known and heavily used protocols like HTTP or database calls. We start trying to unify the structure of how those things get reported. And then we can think of this as semantic conventions. The conventions are, this is the standard way of doing this. And therefore, the open telemetry product will default to this methodology here. And that's like HTTP. We'll see a method. We'll see a status code, we'll see an error code that comes out as part of the HTTP semantic conventions. We'll also see databases, databases, no matter where they live. These are common pieces inside of a database functionality messaging systems, whether they are in QTT Kafka, you pick it, you got it there, or even function as a service, they're triggering functionality for the various serverless environments that are happening. These give us a common vocabulary so that when we start bringing all those things together, be there from multiple environments, the attributes that commonly grouped together are grouped together in the same language, so that we don't have to do additional work to try to understand what this data is telling us. The metrics spaces are similar, but because metrics themselves are different than tracing, there's a set of metric spaces here. Context is it wants to span and correlate so we want to be able to bring the information together, can quickly grasp the point of activity, whether it's over an aggregation of a period of time, or a specific point in time. In this context, this is that in terms of spans here. It really uses the ability to record a measurement. And the measurements themselves can be raw. I want to see a single value of a measure that's a measurement, or it can be a unit of values. Here's the name, here's the descriptor, and here's the units of value here. The metric is a measurement here. It is a single value of a measure, and it is counter. It can be a single point again. Or it can simply be looking at this state that's happening inside of here. And it works in key value pairs. All of this is time series dependent. This key value pair that can be metadata that goes with this. We tend to aggregate metrics over time. You know, again, it's not unusual for a large environment to have tens of thousands of active measurements coming into the back end systems for analysis and response. So if we were trying to watch that data stream one at a time, we probably wouldn't be very successful. And so we want to aggregate up aggregate common functionality up as well as aggregate over time periods that make the best sense for us. And that leads us to this last point, which is really about time, the time that's involved here is the time of the measurement, as well as the time of the aggregation that's involved. So if we start looking at those pieces, this becomes incredibly important to understand that metrics driven from the tracing data themselves. Allow us to look at time as a grouping, as well as dig into any specific point. Open telemetry is incredibly good at this and providing a common basis again for all of it. So the resource SDK, which is letting us have the entity that producing it so that's the representation. And in that we started looking at things like, where is this running. That's the environment things. Is it running on a host is it running inside of a container. What defines the computing environment, and that how did it get deployed. Did it get pushed by Kubernetes. Is it a manual process. And then what makes up that compute unit. So again, you can go from the Kubernetes world to pods to sorry worker nodes to pods to containers to process. And we need to understand how to drill into each of those pieces as well. The resource, the semantic conventions here are that all of these things get defined when we're bringing in the tracing.  If you're not using Kubernetes for instance, you probably don't care about the community side here, but you probably still care about where it's running. What the running environment looks like at any given moment. That gives us the ability to start tying together the application, the communications and the infrastructure into one picture unique inside of this is the ability that we're starting with tracing. So we're starting by looking at the, the application, the user experience, and then driving down to what's affecting that user experience, without necessarily having to change our environments or change our structures or change our underlying language, if you will. So, most recently, logs have come into play here and logs are definitely in early incubating stage here, but it's really kind of important to know this. It is kind of unique and must be possible to map from existing log formats to this data model. And so, when we do this, we've got to make sure that we understand the logging structures that come into play here, as well as new information that may be coming in. So it's got to be semantically meaningful. It's got to be understandable and relate to the underlying structure here. And we have to be able to map between log formats, log format should be able to come in as one and be converted and go out as another, just like we can with collector bring in data from a wire format of one form and push it out as a different one. We need to be able to do this conversions so that we can continue to support things that exist today, as well as exist in the future. And this log translation is simple metal is that log format a should be able to brought into this and go out as log format be and log format be should be no worse than a reasonable direct translation of someone sitting down looking at log a and log b. We can also be able to go from log a to log b back to log a, without losing semantics capability or seeking mantis meaning meaning. We do look at three types of logs inside of your system formats. This is the very honestly these are the logs and events that are operating system puts out to us. And we really don't have a lot of control. We don't can't change the formats. We can't really affect what information is included. And so those are very stable environments and we know what they look like for here. But as I have third party applications here. You can think, you know, standard web servers Apache engine X, we may have some control over what that information includes. We may be able to customize the format. The first party applications, the ones that we are writing ourselves, and we have a reasonable amount of control over the logs and events that are generated. And what information we are getting from those. So, while there are other forms, each of these categories is considered as part of the log specification. Depending what the obstacle look like and how they'll get transmitted, as well as common third party applications or applications that we ourselves are writing. So from very stable to flexible to no limits model, we're looking at all of those capabilities for our logs. When we get into logs, they're really kind of two sets of things that feel inside of here. These are top level named fields. These are fields that we expect are going to her every single time. We're going to see a timestamp. We're probably going to see in logs the body of the log record. That's in software, we're going to see the source of the log record. And so we've defined these top level fields so that we can, again, unify our language. And so our language becomes part of the overall structure inside of here. Because we have a unified language. Now we can also relate those logs easily back to our trace data, as well as our metrics data. And when you start looking at this, this is why we're doing this. It's all around this evidence based debugging. And more likely you're going to go start with a high level metrics.  You're probably going to note something is going a scans with your metric, and you're going to start going into your tracing information here. And then from the tracing information you're going to drill down to it and go to the right places here, even though we start looking at this tracing is the driving force behind all of these pieces. I'm just touching the collector a little bit. I mentioned this here. The collector really is an easy way of getting data in. Then diagnostic use receive process and export data here. It's decent default configurations you might want to treat it here it supports popular protocols. You can see what's going on with the format, even under under higher loads. It continues to run here, and it itself is observable. So you can see what's going on with the collector here. Since it's a single code base can be deployed as an agent can be to support as a collector, and it supports all three data classes. It allows us to offload from the application and changes to the application things like compression and equipment, as well as allowing us to have that common vocabulary the semantics coming in play here. And since it's language agnostic changes are easy. And so we can simply put the implementation into there, and then deal with it in that manner. It's been diagnostic. It's extensible. And you can find functionality for both sides by looking at the collector. You can see things that are in the core, as well as things that are in the community. This makes a great. We don't want data locking in. And so by making use of the collector, our traces are not going to be locked in. And our traces aren't locked in the rest of our data is also not locked in. So the architecture comes into play that goes in the receiver side can be wire formats. It could be Yeager, it could be OTLP can come in from a Korean DSP point and it can be exported similarly. You can choose where how you get it out here. Inside of that you can have multiple classes of processing. You can do a batch processing you can tell it to retry if it didn't see the data. You can go into streaming models here and you can build as many processes as you want. So you can actually deal with multiple functionality. So OTLP could go through and go out as Yeager. Or it could come in and go through a totally different thing and go out as Prometheus and OTLP is your decision on how you're exporting your data through this. So the nice thing is that while we have lots of libraries that are coming into play here. We also have the ability to start automatically. And this is the job example for instance here. It instruments known libraries with no code changes. It's a runtime environment here. It enforce it in here is to those semantic conventions that I mentioned easily. It's configured inside of here and it can coexist if you have something already implemented. There is a warning that does need to come out here. Don't use two different auto instrumentation solutions on the same service. So if you get conflicts in your results will be wildly skewed and probably not meaningful. So keep that in mind. But starting with Java, go grab the Java environment, dropping it into play, and you automatically start getting the trace information that open telemetry can give you. There's additional functionality that's coming out here. The rest of the client libraries are moving to the beta we have a number of them that are rock solid, the tracing environments pretty much a rock solid because they came out of existing production quality functionality here. We're looking at auto tracing functionality for the rest of the the languages that are capable of that. We want to add initial log support. We want to make it as easy as we can. I don't know if we're going to make this year, but we're pushing on getting the log support in here. We need all three other classes of data to go in here. And then we are working on documentation improvements. By the way, we just pushed a whole new series of documentation improvements. We are pushing to get more and more functionality would love to get if you're using it love to hear from you how you're using it. And finally, even though getting started is pretty easy, we want to make it really, really easy for you to get started with open telemetry and start seeing the values of what's going on inside of open telemetry. So, why are you even doing this. Okay, so we talked about the problems you're trying to solve. And I want to bring this back a little bit here. So imagine you're getting pays for an issue. And when that page comes in, you go through a series of steps here. What questions are you trying to need to ask yourself about what's going on inside of here. How do you filter out the noise so that you make sure that the data that you're talking about applies to the situation. How can you determine what isn't causing an issue, because removing pieces is quite often the fastest way to do an underlying cause here. And then how do you determine impact. Again, we talked a little bit about how our instant gratification society means people respond rapidly. They react rapidly to things that are too slow. And so keeping in mind how we determine impact. So we can get into the, the respond and resolve issues as fast as possible. So, you may not want to trace everything, you may not want to span everything, but you may want to end up with what are called necessary services that are showing up here. So we're going back to, why do you want to trace these things. Are you tracing for user happiness. Are you tracing to determine underlying along are you tracing to make sure communications go right. The easiest place to start is with the service boundaries, not the services themselves, but the end points between service calls, as well as calls to third parties, these inferred services that are calling. So you may not be able to instrument your database, but the open telemetry can see that you call the database and measure that functionality. This is an inner process, you don't have to do everything immediately. And that's the advantage again of using the libraries and auto instrumentation is that you can build this over time to make the use of what you want to hear. Keep in mind that this is a lot of information. Open telemetry or data is only as good as we can monitor, analyze and respond to it here. So keep in mind that it's possible to give yourself too much information. Keep that in mind when you're looking at what's going on underneath here that you don't go into this overload condition, where you spend all your time trying to, to break out the noise or to eliminate what's going wrong here. And you want teams that are going to make use of this to do it as close to free as you can get it. So looking at tracing should not be go spend three weeks in a class to learn what tracing is about. Tracing should be pretty intuitive from that viewpoint, and should be as close to being just something that's there. Once you've set up the environment, you should be able to get tracing into the hands of the right people. They can make use of it and that they can quickly understand what the value of it is. So, my next steps really are very simple here. I'd love for you to go check out more about open telemetry open telemetry.io. Please take a look at the documentation pages. Also, we have a getter that is very focused on open telemetry. There's a lot of other subgroups inside of here. The community is a great place to start for this. Finally, special interest groups. There's a ton of them out there as well. You can find a list of them on GitHub under open telemetry as well. Finally, feel free to submit a PR. There's a tag for a label for good first issues if you want to get it or help one if you wanted to join in a project as well. And with that, I'd like to thank you for our time today. And I am all turning back over. Thanks again. Thank you Dave. Does anyone have any questions they want to pop in the Q&A. Good. We have a little time left over. So, fire away. You must have answered all their questions Dave. All right. Remember the, Do you have anything else you want to add? I just, I really strongly encourage everybody to at least go take a look at this. This is probably the biggest single breakthrough in observability by unifying those data streams together. And we'd love to have you come and join us. So I would love for you to see you there. And in fact, I'll look for you on getter. All right. Well, thanks so much for a great presentation. And that is, since we have no questions, we can go ahead and wrap. Thank you everyone for joining us today. The webinar recording and slides will be on later online later today and we're looking forward to seeing you at a future CNCF webinar. So, have a good one and thanks so much. Thank you. Bye bye. Bye.


A firefighter sprays a hose at a home while the surrounding neighborhood burns. Seven months and one day after the October 2017 wildfires erupted in Sonoma County. We were 99% complete as of today, having removed 2.2 million tons of debris, which equates to nearly 314 square miles of fire area that's been cleared. A momentous update given the magnitude, complexity, and self-imposed timeframe for the debris removal process. From the beginning of this very catastrophic, very devastating event, the response has been a one team one fight effort. A similar accomplishment and announcement the very next day in Ventura County. The county, the city, the state, and the federal resources all coming together as a team and fighting back and the cooperation was seamless. We move more than 18,000 firefighters through our fantastic mutual aid system and all other kinds of assets to roll into and try to minimize the overall losses, but there were losses. The ferocity and unstoppable. Facebook handle typed as california underscore OES.