Hi, everybody, and welcome to the Kubernetes Code of Conduct Committee Community Update 2020. My name is Ava Black and I am the open source program manager for the Confidential Compute Team at Azure. My pronouns are they and them, and here with me today is Karen. Hi, everyone. I'm Karen Chu. I'm an open source community PM on the Container Compute Up-True Team, also at Microsoft Azure, and my pronouns are she and her. Let's get started. All right. So in today's session, we're going to talk about the current state of the Code of Conduct Committee, including who our members are, what our purpose is, what our scope is, and our plans in progress around documentation. I want to start with a little bit of background about the committee and our organization and our relationship to steering. There are five members of the committee, three in addition to Karen and I. We also have Tasha and Tim at VMware and Celeste at the CNCF, and the five of us are elected or appointed by steering, but then given separate powers, we don't actually report to steering, one of the few committees that doesn't. This was intentional. Both of these committees are intentionally separate to hold each other accountable if that need ever were to arise. Also to note is that no more than two members of the Code of Conduct Committee are ever from the same company, and this avoids a perception of single-party control. It avoids any situation where conflict of interest might arise, and if one were to arise, members of this committee do recuse ourselves from dealing with that, and so there's enough of the committee still engaged in something, even if, let's say, something happened involving one of the companies. Now, our purpose as a committee is to provide and support and enforce a well-considered viewpoint of what constitutes acceptable behavior within a community, within our community. To do this, we focus on a restorative model that believes in the inherent good intent of all members of the Kubernetes community, and we also believe that codes of conduct in general do not need to be punitive to be effective. Let's talk about the scope of the committee. Here we've mapped out some examples of environments that fall between official and unofficial spaces as well as online and offline spaces. The committee is invested in all these different quadrants because they may involve community members and may affect both the health and behavior of the community. Eva, do you have some examples you want to share? Thanks, Karen. I'd love to. So while the obvious spaces online might be our GitHub and our Slack, or offline might be things like the Linux Foundation events, the Kubernetes, the KubeCon, like this, there are less obvious ones. Our podcasts and streams that people run or a personal Twitter for a SIG lead or an official meetup or an unofficial meetup or even just a couple community members gathering together at a local coffee shop to hang out and talk about what's happening in their working group. Because all of these are spaces filled by members of our community acting in Kubernetes' interests, we feel that this is part of what makes our space safe and welcoming for everybody. And especially true for folks who are in a leadership position in the community. It's important that they reflect the values of the community and make it a safe and welcoming space for everybody. All right, next we'll talk about committee relationships. So depending on the environment, sometimes we work in conjunction with other parties where the next is to communicating with all these groups when there's an incident or concern, no matter where in the community it may have come from. So we're often involved in routing, helping to gather information if needed and deciding what actions to take. But we're often not on the front lines because all these bodies are empowered to act in their respective domains. So think of us as tier two support and let's dive a little deeper into each of these bodies. With SIG contributor experience, we loosely advise them on what they have questions around like cultural aspects. So that's something we'll work with them on. What Slack and GitHub admins, they're the frontline admins in their spaces. So not only do they have the jurisdiction over their spaces, they're also the ones to perform the administration of it and help keep it free from spammers and drive by trolling. But in rare cases, they will reach out to the code of conduct committee, mostly in gray areas or if there's a repeated issue. And lastly, when in-person events are a thing again, the Linux Foundation event team members are the frontline admins for those spaces because they're legally responsible for venues, for managing events staff, hiring security, et cetera. Nonetheless though, we are there for them to help provide backup and to provide support for the community during face-to-face events. So what we do to foster an inclusive and welcoming environment, as Karen mentioned, sometimes we support working groups, but we also support community members directly. So if you are leading a working group or involved in one and would like our input on something you're writing or doing or you're working group and watching our engagement early on, please just reach out. But if you feel like an incident has happened and it's very subjective, also please do reach out. What does that mean to say an incident happened? Well, if any series of interactions feels non-inclusive or combative or someone has an ill intent, it's subjective. There isn't really a strict rubric for this, but we're all human. And historically we've found that the majority of bad actors that we've seen were not actually part of our community.  And while we have found that there are, generally speaking, a very small percent, but some bad actors in any system, we don't ask, we don't expect anyone in the community to distinguish between these if it feels unsafe to do so. We've chosen to take on and accept the responsibility of doing that emotional work here to differentiate between a legitimate concern or grievance or folks that might be trying to abuse the system or abuse and cause harm. This space is very nuanced and I want to just reiterate that we know we're all human, we're all trying to do our best. And if non-inclusive behavior seems to be happening, I'm gonna talk you through a little bit of what our thought process is and how we respond to that. We asked ourselves some hard questions to try and understand the greater context and what people's intent was before coming to any conclusion or making any decision. And I'll give two examples, both happened on GitHub. To Karen's point, the GitHub admins were the ones that handled these initially, but both were gray enough that they came to our attention. In the first example, a maintainer was perceived as sort of over-aggressively closing issues and the contributor got very upset, eventually fired off some angry comments on GitHub and both of them reached out to the Code of Conduct Committee to say, hey, something's wrong with the person's being bad. We investigated, we talked to both people separately, we looked at the GitHub histories and realized that this wasn't an intentional harm. The automation had over-aggressively closed things and so the contributor in this case didn't realize that their issues were being closed not by a human, but by a bot and their anger was misplaced. Meanwhile, the maintainer realized that the automation tools they were using were closing more issues than they meant to and so they were able to modify the tools to better represent the intent they wanted in the community and I'd say the outcome from this was pretty positive. Yes, and feathers were ruffled in the beginning, but both people are still members of the community and things improved. Now for a second example, this happened after someone had just joined the community and began opening their first couple PRs because of the demographic that they represent, they got targeted on GitHub and someone began posting harassing comments on their PRs and they were kind of ignoring it at first but then it continued to happen, this came to our attention and upon looking into this, we realized that the harassing comments were coming from someone who first of all wasn't a regular member of our community but they were harassing people about demographic all over GitHub. They were just sort of a drive-by troll who happened to come into Kubernetes space and cause trouble here. And so in that case, we did reach out to the GitHub admin team and asked them to just block that person from our spaces entirely, kind of a last resort but it seemed prudent in that space, in that incident to make our space safer for everyone. All right, so let's now discuss providing restorative support for our community and focusing on harm reduction. So our intent is to safeguard and build trust in the community and all communications with the Code of Conduct Committee is confidential. This is a safe and private space when you come and talk to us. And what exactly does that mean though? So with whichever means of communications you choose to utilize, we never disclose to one party what another party is said about a situation. And additionally, we seek to verify reports without exposing the claimant while also avoiding potentially causing more emotional distress or jeopardy for that matter. Timeliness is important to all of us. So when you contact us, we'll try to provide a response within a day and depending on the scenario, we may reach out for more information. Just remember, our goal is to find a path towards community healing and individual growth and punishment is really our last resort. And where can you go to reference all of this? So the committee is still fairly young. We have a lot to do but we're committed to updating and publishing documentation around our goals and standardized processes. We're hoping that by making everything public and transparent, the community will have clear expectations when it interacts with us. So some of the docs that we're working on include how we receive reports and triage them, how we handle recusals, how we handle the logistics of incident response, educational materials that we can point the community to and we're hoping to publish transparency reports in the near future. Earlier, as I mentioned, we also work often times with other bodies that deal with code of conduct matters. So we're working on formalizing expectations and communication channels with these groups. This effort will also help define our scope better. So we're ready to find us. If and when you need to reach us, you can email conduct at kubernetes.io to reach all of us at once, but if you do wanna reach out to us individually, you can just DM us directly on the kubernetes Slack. Our job is to be here for the community. So as we mentioned, you should get an initial response back within 24 hours of reaching out. Now, if you are a SIG lead or a working group lead or involved in those, like I said, by all means reach out. You can get engaged with us directly and early on. And if you, we want everyone to feel safe, bringing their whole and authentic self here. So if you feel like something is off or something is wrong, please reach out. Please know that also our work happens mostly behind the scenes. So you may not really see it until we get all of our processes matured enough to create transparency reports. You might not see what we're doing in the community unless you're in one of those SIGs or working groups working with us, but know that we're here supporting you. Thanks for coming to our talk and we'll stick around for some questions. Thank you.


Hello everybody and welcome to EmberConf 2022. Last year I gave a long and winding description of the history of Ember and how we evolved our approach to evolving the framework. This year I want to talk about the next big phase in Ember's evolution, the Polaris Edition. Before we get into Polaris, I want to talk a little bit about what Ember is. People often ask me, if Ember is evolving to adapt to the ecosystem, then what is Ember? What makes Ember 1.0 the same framework as Ember Polaris? At a basic level, the answer is Ember apps. Ember apps built a decade ago, including Skylight, the app I work on, smoothly evolved from a world where the dominant frameworks were a backbone and knockout, a world before ES2015, and a world where Bower was the dominant way of getting assets into your front-end app, to a world with bundlers, MPM, and TypeScript. Ember and many other Ember apps managed to maintain momentum over a decade, while smoothly adapting to the ecosystem around it. In a nutshell, Ember is a framework that prioritizes making that possible. Ember is for you if you want to build long-term products together with other people. So that means that an Ember app is a long-term product built together with others. When I say others, I don't just mean other developers. I mean developers, of course, but also designers, DevOps folks, marketing and sales folks, and all the other people who make a product tick. Now what is a product? Well, for one thing, a product is more than just a user interface. Of course, a product includes a user interface, but a product is an end-to-end experience built for customers and their needs over time. Ember is a product framework because the source code you write in an Ember app describes the way it works across many different facets of a product's lifecycle. A product is developed, tested, continuously integrated, and released to production. So Ember's authoring format and its public APIs support all of those modes. Your route, component, and service definitions run in a development mode server with assertions and other niceties that are too slow to run in production and are then automatically stripped out if you ask Ember to build a production build. The thing that makes Ember a product framework is not that it's possible to create a development or production build. Basically, all UI frameworks do that. It's that we design our app and add on APIs to support those modes without you needing to understand it. Similarly, just using Ember's testing APIs as documented will give you out of the box local in-browser testing as well as testing in CI. You don't need to learn about how to wire up or configure your tests. You just write them, run them locally in development, and the same source code runs in CI. And because these details are part of Ember's public API, we can adapt to ecosystem changes over time, like the migration to Babble, changes to Babble over time, the rise of GitHub actions, and many other changes without requiring you to learn about those things and update your app's setup and configuration to take advantage of them. Which brings us to the second thing that makes Ember tick. Ember is for people who want to build long-term apps. When I say long-term apps, I mean products that outlive the ecosystem trends that were popular when they were created, and frankly, many more trends after that. Long-term products need to adapt to changes. A lot of changes represent important innovations, and they need to do that without long feature pauses every few years to significantly retool the application. A good long-term product maintains its momentum. Customers have no idea about big technical changes, and it's rarely acceptable to tell a customer that a feature that they want is on long-term pause while you migrate your entire code base to a new paradigm. Long-term products take advantage of innovations on behalf of their customers without grinding to a halt. When we say that Ember is a long-term framework, we mean that Ember is designed to help you with this problem. When you start a new Ember app, you're of course targeting today's tools, web browsers, packages, and techniques. But a few years later, a long-term product targets a new set of tools, web browsers, packages, and techniques. It's how progress works. As a long-term framework, Ember takes on the responsibility to keep up with those changes and help applications smoothly migrate over time without the need for huge feature pauses. This is a feature of Ember that doesn't appear in any feature comparison checklist. Each version of Ember incrementally migrates Ember applications along with the ecosystem. You probably wouldn't notice that except when you look back a few years later and try to imagine where your app would be if you had hand rolled something at the beginning and updated only when you really needed to. What I mean when I say that Ember is a long-term framework is that when we change our recommendations over time, we invest in a detailed, worked out migration strategy. This applies just as much to new idioms as it applies to breaking changes. One example, our policy is that before we turn on a deprecation in stable Ember, we first land the feature that you're supposed to migrate to and write a migration guide how to go from the deprecated feature to the new feature. We don't do that before we remove the deprecated feature. We do that before we tell Ember users that they should move away from a pattern. I bring up Skylight a lot, but it's because it's honestly astonishing to me that a code base that started 10 years ago is somehow aligned with today's ecosystem, even though we started in a world that predated even Bower. I know that we don't always think about things this way in the Ember ecosystem, but Ember has gone through a ton of these sort of changes. Early on, we added Ember CLI, moved all apps to ES modules, actually before ES 2015 even landed. We adopted promises for Async, we landed Glimmer, a whole new rendering engine, we've migrated to JavaScript classes, Glimmer components, the whole reactivity model and PM packages and the list goes on and on. And along the way, we've always kept the old world running alongside the new world, providing a path for apps to keep building features while incrementally moving to the new patterns. And we adopted all those changes in Skylight, even as our team gained new engineers across the experience spectrum. At this point, all the developers except me who work on Skylight weren't even there when we created it, which brings me to the final piece of Ember's formula. Ember is for products that are built together with others. Products built together have little time for Rockstar Ninja developers throwing together their pet theory and foisting it on to the rest of the team. When product teams build their apps together, we think about what future team members will think about decisions we make today. Since future team members will, by definition, come from outside of our team, we prioritize solutions that we can share with the ecosystem rather than solutions that we build in-house. One thing I've seen a lot in teams that valorize Ninja development is this, someone will put together a bespoke in-house solution and put it together in the code base. A few years later, that team member has moved on to a new company, and everyone else is stuck with the consequences of the original developer's hubris. If we're really thinking about our future team and not just our current team, we focus on using shared solutions whenever we can. So then what does it mean for Ember to be a together framework? It means that we focus on making sure that people can pull out slices of their apps into add-ons very easily. This means that add-ons in Ember are slices of products. They support running in development and release builds without any configuration. Because they are built using the same authoring format as applications, they support testing both locally in a browser and in CI, again without any special configuration in the app. When written idiomatically, they support server-side rendering, Clyde-side rendering, and rehydration. And add-ons are also slices of long-term products. By using Ember's authoring format, they take advantage of Ember's strategy for migrating apps along with the ecosystem. And when changes are necessary, changes to add-ons automatically propagate to all applications that use them. So add-ons are an essential part of our strategy for making big changes in additions while allowing apps to maintain feature momentum. So is Ember for you? If you want to build long-term products together with others, then Ember's design and process for evolution is for you. On the other hand, if you're building a short-term product like a temporary microsite and you're doing it on your own, you'll probably find that these aspects of Ember's design get in the way. So today I want to talk about Ember's next addition, Polaris. I'm so excited about how awesome Polaris is going to be. We're going to get template tag, tree shaking, code splitting, track built-ins, resources, type script, accessibility. Now you're probably thinking, is that even possible? Is it going to take us five years? If it takes five years, will Ember still be around in five years? Well, the answer is yes, we can do it. To prove it, I wanted to take a closer look about what we were able to accomplish and octane together. One thing worth noting, the work of Ember additions happens over a few years, but the exciting progress, the part where wide swaths of the community can start using the features is concentrated at the end. So I'd like to take a look at the octane timeframe as a way of calibrating how far along we are with Polaris. Most years, when I sit down to work on the keynote, it feels kind of boring. Yep, we made some more progress, some more progress here. Honestly, that's kind of true this year too, but I thought maybe I could try to unpack what some progress and pretty close means when it comes to octane and Polaris. In some sense, almost all the features of octane are centered around a shift from classic classes to native classes, and generally de-emphasizing the role of the big component superclass in favor of smaller pieces that work well together. So instead of object.ext, we get class extends. Instead of properties pretending to be fields, we get fields. Instead of a custom init function with a special implementation of super, we get a class constructor and built-in super. Like always, native classes landed alongside classic classes. You can subclass a classic class, and you can use classic features like computer properties and native classes. That's a lot of the word class. For simple cases, we wrote a code mod that does the transition for you. So Ember apps could keep shipping while incrementally moving to native classes and use native classes in new code. Building on the migration to native classes, octane also introduced a new reactivity model. Prior to octane, Ember had moved to a unidirectional data flow model. The process started with Glimmer 1 in 2015, and we finished the job when we made backtracking, re-render, and error in Glimmer 2. But a lot of the inner workings of the reactivity system were still based on the legacy of Sproutcore 2 and the cocoa data binding system that inspired Sproutcore. In octane, we took the reactivity system that we used inside of Glimmer to model unidirectional data flow and made it the reactivity system for your entire app. Basically, here's how it works. You start by defining your mutable inputs. These are the pieces of mutable storage that will cause the DOM to update when they change. You then use those inputs either directly or through functions and getters in your templates. Ember automatically keeps track of which inputs are used in each output node and keeps the outputs up to date as the inputs change. Here's how I like to describe it. Your data and computations live in a data universe, and you can understand the data universe completely without knowing anything about the output DOM. And the output DOM reads from the data universe to keep itself up to date, and that backtracking re-render thing, that's just another way of saying the same thing. The render process reads data from the data universe. It shouldn't be writing to it. Now, you write to the data universe inside of an event handler or other browser callback. In this example, we're incrementing a counter inside of a click handler. Internally, we remember that the counter was updated, but we don't do anything else yet. You can immediately read from the counter or call functions and getters that use the counter and they will immediately get the new value of the counter. You don't need to wait until another render. The data universe is always internally coherent. Now, since something changed in the data universe, Ember schedules an output re-validation, which will happen after your event handler is all done and you've made all the changes you want to the data universe. When that happens, Ember will discover that this node used the count field before and that it has changed since the last time we checked. So the output node then reads from the data universe to get the most up to date answer. After that, all the nodes in the output DOM are up to date with their inputs and Ember waits for more changes to the data universe. This whole system boils down to three very simple rules. One, you mark your mutable state as tracked. Two, you use normal functions and getters to compute state and you don't need to annotate those at all. And three, finally, you access that data in your template and Ember will keep it up to date. In case it wasn't already obvious, we call this system autotracking. What I really like about this model is that it's basically the Excel model that says it's pretty understandable to a lot of people. And it's fast. Ember only computes the value of DOM nodes if they might have changed and it can quickly zoom in on the specific nodes whose inputs have changed. But getting back to our main theme, what's truly mind-blowing about this is that we landed the activity model alongside the old computer property system and we made sure that it would be possible to incrementally migrate from computer properties to autotracking. And not only did we make sure that classic computer properties could be used in classes that use autotracking, we made sure that classic classes could use track properties and even getters. Internally, there aren't two systems. There is a single autotracking system that was designed to be expressive enough to support classic features. Doing all of that work might seem counterintuitive. Surely we can go faster if we just built a new system from scratch and kept the old system working and not spend all this time on interoperability. That's what React did with hooks. You can still use classes in React, but you can't use hooks in them. It's a great idea when you don't consider the implications of long-term apps. Long-term apps need to adopt changes like this or risk getting stuck in the past. But in order for apps to maintain momentum through these changes, they need the ability to migrate incrementally with good interoperability between the past and the future. Now, the work on Glimmer 2 didn't just give us the design for a new reactivity system. It also gave us a much better design for components. Instead of a DSL in which you describe the root element in JavaScript completely differently in the app, Octane components just use HTML for the root element. And instead of putting your JavaScript and template files in two really separate locations, you can put them right next to each other. Similarly, instead of adding behavior to elements through mixins, you can define behavior for elements in standalone modifiers. One nice thing about this is you no longer need a component class just to give behavior to an element. In Octane, component classes exist purely to add local state to your component. Everything else that was done with lifecycle hooks components can be done with modifiers in Octane. And once again, Octane components are not a separate system that lives alongside the classic system. You can use angle bracket invocation to invoke classic classes, and you can use modifiers in the templates of classic components. And you can invoke classic components from inside of Octane components. Under the hood, this works because Glimmer only has one kind of component, and components define their precise behavior by giving Glimmer a component manager. In order to allow classic components to be seamlessly with Octane components, we made sure that the component manager API was expressive enough to describe all the interesting features in classic components. By investing in interoperability between classic components and Octane components in the core architecture, we made it possible for apps to begin using all of the new Octane features in new code without worrying about what that would mean for existing code. And over time, apps could incrementally move components to Octane, either by using code mods to help automate the process, or whenever they happen to touch a file containing a classic component. We also added built-in support for NPM packages in precisely the same way. In Octane, you can just import from NPM packages, but that system lives side-by-side with the classic app.import system, allowing apps to start using NPM packages directly moving forward without breaking existing code written before everyone had standardized an NPM. In order to live in the future, we need to migrate from the past, and it doesn't slow us down. In our view, we get to the future fastest when we move smoothly, not by stopping the world on a big adopt-the-future migration project. So now that we took a look at Octane, I want to talk about Polaris. Just like Octane, Polaris brings a whole bunch of new awesome features to Ember apps and helps Ember apps take advantage of innovation in the JavaScript ecosystem. And also like Octane, Polaris builds the future alongside the present with an eye towards a smooth migration process that lets apps use those exciting new features in their own code. So Polaris is Ember's next addition. It builds on Octane's reactivity model and closer alignment with JavaScript standards. Polaris will align Ember with the modern NPM package ecosystem, bringing zero config code splitting per route, automatic tree shaking of unused Ember features, excellent built-in TypeScript support, and templates that can directly import their dependencies. Let's dig in. I want to start with my personal favorite feature of Polaris, and that feature will have the biggest impact on your day-to-day work, the first thing that the new template tag feature lets us do is import components using JavaScript import syntax. This gets us away from Ember specific resolution rules that you have to learn and lets you use the same import statements that you use everywhere else in your app. The primitives necessary for template tag have already landed in stable Ember, and you can use it today in your app with the template imports add-on. But that's not all we can do. Now that our templates are in JavaScript files, we can use normal JavaScript functions in the same file and invoke them directly from the template. The signature of a function called from a template is exactly what you'd expect, no extra ceremony. This feature is built on Helper manager, which has already landed in stable Ember. You can use it today with the Ember functions as helper polyfill add-on. Yes, that's a very long name. Same deal with modifiers. You'll be able to write modifiers in the same file and invoke them using natural syntax. This feature is based on Modifier Manager, which actually landed before Octane, and the design for using plain functions for modifiers is in progress. Now, I'm personally working on a library that explores unifying helpers, class-based helpers, modifiers, and resources, and I'm pretty happy with our progress there. If you want to learn more, check out StarBeam on my GitHub. Incidentally, Polaris will include an API for creating modifiers, so you won't have to learn about and install a package for that anymore. All that's great, and it's nice how much you can do without needing state in your component. But if you do need local state, you make a class just like in today's Ember. Instead of putting the template in a separate file, you put the template right inside the class. One thing I really like about this is how natural the upgrade is from a template without any internal state to a template with state. And I also love the fact that you can use functions instead of methods in more cases. To get a flavor for how this would work out in practice, I slightly changed the example so that we're counting inches instead of just numbers. To format the inches, I used the Intel.NumberFormat API. As an aside, I think the Intel API is genuinely epic, and people should use it more. End of aside. The key here is that the describe function is just a normal function, and you can break it up however you would normally break up functions in JavaScript. I can easily pass a specific locale to the describe function. And if I want to take named arguments, I just take an argument as the final parameter. In other words, if you want to function in your templates in Polaris, you write a function. And if your locale was stored in a service and was reactive, that would work just fine. In general, you can mix and match these features as you'd expect. So that's the status of template tag. If you're feeling adventurous, you can try it out today in stable Ember apps by installing the Ember template imports add-on. The second major pillar of Polaris is the reactivity system. This is the area I personally dedicate the most time to, so I'm going to have to restrain my enthusiasm and avoid spending all of my time on this topic, but it is pretty awesome. First of all, I'd like to define reactivity because it can be the subject of confusion and controversy. My goal with this definition is to cover all of the major UI frameworks. In my opinion, people correctly have an intuition that front-end frameworks are doing something reactive and I think a useful definition of reactivity should go with that intuition. In user interfaces, a system is reactive if it has reactive inputs, a mechanism for computation, and reactive outputs described in terms of those computations. And the system is responsible for keeping the outputs up to date as the inputs change. The programmer described the connection between the inputs, computations and outputs, and does not write code that updates the outputs manually. Now, you might be thinking that I came up with that definition so it only applies to Ember, but the opposite is true. Sometimes people say that react is not reactive and I got to say I'm not the biggest react fanboy to put it mildly, but I think that's pretty silly. So now that we've defined reactivity, let's take a look at octane reactivity with that in mind. As you can see the person class is a normal JavaScript class with normal JavaScript fields. I use TypeScript syntax here for documentation basically and we added some annotations to the fields to say they're reactive. What does it mean to say that the fields are reactive? So far, not much. The person API is exactly the same with or without the tracked annotation. You don't have to wait some amount of time after writing to name before you can use the description getter. When we say that the fields are reactive we're actually talking about the output. When a field is reactive and a computation based on that field is used in a template Ember will automatically keep that output up to date. We can summarize the philosophy of Ember reactivity like this. You mark your mutable state as tracked you use normal functions and getters to compute the right values. You use the computations in the template and Ember keeps the output up to date. If we want to get a little more specific we have a hard and fast rule. You should read and write track state in exactly the same way as you read and write normal JavaScript. If you remove the annotations the behavior of the class itself is exactly the same. You can write a suite of unit tests against the class remove all the tracked annotations and the tests will still pass. Now let's look closely at track fields and see how they satisfy these rules. First of all the reactive name and location are stored in JavaScript class fields. We annotate those class fields with decorators which allows Ember to keep track of them when they are written to and when they are read from. The final thing we need to check is whether the code has the same behavior without the tracked annotation. In practice this means we need a way to intercept all reads and writes of the underlying storage but then do the original read or write. In this case we use JavaScript accessors behind the scenes to intercept the reads and writes so we can record what happens but then we always do a normal read or write afterwards. So if we create a new instance of person and check its description we get the value that the getter computed. If we then remove the tracked annotation we get the same behavior. So we got the job done. Track fields follow our rules and we ship them an octane. But let's take a step back and ask why do we care about these rules. Basically because they give us a reactivity system that allows us to think about our data in normal JavaScript terms and then layer on reactivity by saying mutations to this field should be tracked because I want the output to update when they change. You use normal JavaScript functions to concatenate strings, filter or map arrays or build intermediate data structures. And you can see the result of those computations immediately because they're normal functions. And perhaps more importantly all that works in a file containing a component or in any other file in your application which means that you can refactor reactive code from your components into separate files freely. This might all sound very boring and obvious but believe it or not Ember is the only framework that uses normal JavaScript access patterns to read or write data and allows you to use those access patterns in any file. This gives us a general recipe for creating more reactive data structures in Ember. We build Ember's reactive data structures on top of JavaScript syntax or APIs. We provide a way to annotate the JavaScript features so we can intercept, read and write to the data structure and keep track of them. And we confirm that the reactive data structure behaves the same with and without the annotation. Now, tracked fields are all well and good for single pieces of data but sometimes you want to use other data structures like maps and sets. And you'd like to be able to do that without needing to learn convoluted patterns for manipulating maps and sets by creating new maps and sets. Also, if you change a single entry in a map you would like to use any other part of the map. Okay, so Polaris will add new reactive data structures that follow these rules. Let's see how we can build a reactive map by following the recipe. I made a simple example of a shopping cart class that uses a map internally. It lets you add and remove shopping cart entries and get all the items as a cart. Pretty vanilla stuff. Now we'd like to make it reactive so I can loop over the cart in a template and have it automatically update when I add or remove items. Step one is pretty straightforward. We're turning JavaScript map into a reactive map. Now we need some way to annotate the map as tracked. Because map is an object and not special syntax like fields we can use a function to mark it as tracked. Since map is a JavaScript class we can implement an equivalent API that uses map under the hood but allows us to intercept the reads and writes. And removing the call to track brings us full circle. The behavior of track map is exactly the same as the behavior of regular map. Okay, so Polaris will include track maps. The primitives necessary to build track map have already landed and you can use it today via an add-on. I have and it's awesome. But we can do way better than just adding track maps. Polaris will include tracked versions of object, array, map, set, week map and week set. For example, here's the same principle applied to arrays. Instead of needing to learn obscure patterns for manipulating arrays by creating new arrays you can just manipulate arrays directly. All of these track built-ins follow the same fundamental rule. If you remove the tracked annotation the behavior of the code that uses the built-in will remain the same. And they're all available today in an ember add-on that works with stable ember built on top of stable primitives that have already landed. Next up I want to talk about embroider. Talking about the details of embroider can get pretty weedsy so I want to try to ground it in a basic goal. Ember apps should be able to add features and screens to their apps without affecting the bite size of other pages especially the critical path. Now this is not a minor detail. If adding features fundamentally slows down your critical path you're forced to choose between keeping your critical path snappy or adding features that your customers want. Our work on embroider has been grounded in this goal to end this terrible choice for every ember app. So every ember app can add new settings pages, admin sections and lesser used features and never have to worry about slowing down the critical path. Goffrey is going to cover the details in a bit but the big picture point is that Polaris brings a big change to how ember apps interact with external packages. In short, Polaris apps and add-ons will use node package resolution to import dependencies. This means that Polaris apps will be built using ecosystem bundlers which means that idiomatic Polaris apps will get features like tree-shaking and code-splitting without having to know anything about tree-shaking or code-splitting. Let me show you what I mean. These days ember apps can import from external npm packages which is great but there's still a problem. We still produce a single vendor.js in a bundle containing all of ember and a single app bundle that contains all of the code in your entire app. This is what makes adding new features anywhere in your app slow down your critical path. What we'd like to be able to do is build a bundle for a specific critical path. Ember apps are already organized by route so our app is already organizing the entry points that we can split apart. In this app, the home page is a critical path. It has a handful of modules in it and we'd like to build a bundle that only contains those modules We're not using these other routes so we don't need to include them. We're also not using these framework files so we don't need to include them either. We can then take this much smaller collection of JavaScript and turn it into a bundle that can be shipped to a browser. The good news is the JavaScript ecosystem has developed a bunch of different tools that know how to solve these problems. Instead of transitioning from our current ember bundler to a new ember bundler, embroiderer is going to use knowledge of ember routes to define our entry points We didn't mention it yet, but embroiderer is the codename of the project that makes all this work. Embroiderer has already shipped an ember but it's not on by default. If you're adventurous, it's pretty easy to try it out. And don't worry, you're not going to have to decide which bundler to use, learn how to configure it, learn how to keep it up to date. After you upgrade to Polaris, Ember S will still work. Ember build that trash release will still work. You'll be able to run your tests locally in a browser and in CI release builds without any new configuration. Polaris will probably use Webpack under the hood but neither you nor your app will need to know that. If you want to use Webpack features in your app, you can. If you want to use Rollup instead, you can. Safe in the knowledge that the add-on ecosystem doesn't depend on any specific bundler. To get the full benefit of Embroiderer and get code splitting at route boundaries in your app, you're going to need to do some additional steps. Mostly, you'll need to ensure that you're not using any deprecated dynamic features like the dynamic component helper. You will not need to migrate away from any idiomatic octane behavior. Since the add-on ecosystem is still working on Embroiderer support, adopting Embroiderer today sometimes means helping add-ons that you use migrate to Embroiderer. So this is what it's like to adopt Embroiderer today. But when Embroiderer is on by default and included in Polaris, the process will be streamlined. For one thing, we will feel confident enough in the compatibility mode to turn it on by default so there is no step one. For another, assertions about incompatible add-ons will be incorporated into the framework. They'll say something like, this add-on is not compatible with route-based code splitting, and they'll be quite rare because finalizing Polaris means that we've achieved broad support in the add-on ecosystem. Which means that this whole list will boil down to eliminate uses of deprecated dynamic features using code mods and Ember standard deprecation workflow. In other words, the standard way of upgrading to a new addition. So in summary, here's the story. The primitive and high-level features have already landed including code splitting and tree shaking. Many add-ons are already compatible, but there are still a number of add-ons that aren't. There's also a long tail of obscure compatibility issues that we will need to address before we can turn embroider on by default. Now, all the weird jargon and finniqueness of the details make it easy to forget what this is all about, but this is a big deal. Soon, every Ember app will be able to add features without slowing down their critical pages, and that won't require a huge rewrite to a different framework or even a stop-the-world incompatible upgrade. You'll upgrade to Polaris, incrementally work through deprecated dynamic features, and boom. Ember apps written before code splitting even existed will have route-based code splitting by default. Ember is amazing. The next big Polaris feature is TypeScript. But let's take a step back for a second. Ember CLI TypeScript is a thing. It gets over 500,000 downloads a week, already supports Ember API really well, has good support for Blueprints, templates, a good versioning story, and most importantly, it exists today. So what am I talking about when I say that Polaris is going to ship TypeScript in Ember? Can we already do that? In fact, it has very little to do with implementing types for Ember. The typed Ember team already did most of the work there. Instead, shipping TypeScript in Polaris means incorporating TypeScript types into our design, code base, and documentation, as well as our semver commitments. To make sure that TypeScript types are a first-class consideration in our design effort, the typed Ember project has become an official Ember core team, with the authority to write and review RFCs, and instead of reacting to Ember designs, we have a proactive role in the design of new features. Because so much of TypeScript in Ember is a matter of policy, I thought we would take a look at how the TypeScript RFCs describe what we're doing. After a truly massive amount of conversation, back and forth in iteration, these RFCs are now approved, and they reflect the consensus position of the project with regard to TypeScript. So I pulled out a few snippets here. First of all, the most important consequence of first-party TypeScript support in Ember is that the types are published and this has a benefit that may not be obvious. You get up-to-date types in beta and canary builds in temporary forks of Ember and in every pull request. This means that Ember's APIs evolve together with its types. Second of all, adding support for TypeScript should not mean that we violate Ember's semver commitments, more on this in a minute. Third, adding support for TypeScript does not mean that we think everyone should use TypeScript. We want JavaScript users to be able to use Ember, and we don't want any part of Ember's API to make sense only to TypeScript users. And fourth, not only do we not want to make TypeScript mandatory, we don't want our adoption of TypeScript to degrade the experience of JavaScript users. This last one is based into how TypeScript itself is designed. Unlike most Type languages, TypeScript will compile and run your code even when there are Type errors. TypeScript types drive the JavaScript language supported in VS Code, even in pure JS files that don't have a TS config, JS config, or any reference to TypeScript anywhere. This means that stuff like document.createElementForm, that AdventListener submit gets to right behavior because the TypeScript team has published types for the DOM and also Node. They have also invested in genuinely groundbreaking features to make all this work. Similarly, when Ember invests in high-quality types for Ember, that improves the experience for JavaScript users. And that will even apply to things like block params and template tags in JavaScript files. If the component you're invoking has types, JavaScript users will get tab completion, hover documentation, and other editor support for that component. Of course, the built-in components in Ember will have types. Our investment in TypeScript is intended to be a win-win. TypeScript users get more integrated support for types in Ember and JavaScript users get the benefits of more integrated types in their tools. Like I said, the TypeScript team built TypeScript so you can build an idiomatic JavaScript API first and layer types on top. That's how things like the DOM work. And that's our plan. But there's a problem lurking here. Every version of TypeScript comes with a list of breaking changes and some of them are pretty significant. We said we didn't want TypeScript to compromise our Sember commitments, so what are we to do? First of all, we need a definition of Sember for TypeScript. We landed on this one. If your code base had no type errors before an upgrade to a new version of TypeScript, it should have no errors after the upgrade. And this should be true for any supported version of TypeScript, even versions that came out after the version of Ember you're upgrading from. This is not an easy problem to say the least. But the typed Ember team has years of experience iterating on a workable policy and they put together an RFC describing the approach we're going to use. One thing that makes me pretty proud of the work we did here is the participation of the TypeScript team in the RFC thread. We'll probably iterate on the solution some more as we get even more experience with it, but I think it's a pretty good place to land. Because we're not the only library-shipping TypeScript types that use a Sember for versioning, Chris Kreitschow adapted the RFC for general-purpose use and put it up on Sember.ts.org. It's still in draft form, but I hope that the wider ecosystem sees the value in this and that we can work together on idioms and tools to make it easier for people to commit to stability around their types. Lastly, I talked about template tag earlier and it goes without saying that Polaris will support types in template. The project to make that happen is codenamed glint and you can try it out today. We've been using it at Tilda for a while now and the Ember TypeScript team has done a great job with it. Definitely check it out if you use TypeScript with Ember. If you want to get the full scoop on TypeScript in Ember, check out the road to TypeScript later today. And finally, there's one last pillar of Polaris. This one is a new area of focus for the whole Ember team and it has to do with the way that Ember is a product framework. Ember apps are products built to run on the web and there are web browsers on desktops and laptops, of course, and web browsers in phones and tablets. But there are also unusual ways of interacting with the web, like on televisions. Edge for the Xbox is a full-fledged browser on a television that you can really use, but it doesn't have a traditional keyboard or mouse. There are web browsers in VR headsets, on watches, and in kiosks. And of course, there are many people interacting with the web through assistive technologies. The reason we build products on the web is because of the amazing reach of the web. When you do a good job building something on the web, it works not only on devices you've thought of and not only in devices you didn't think of, but also on devices that don't exist yet, or versions of operating systems that didn't come out yet. The original Space Jam website, which was discussed in the pre-conference talk Space Jamming Accessibility, was created in 1995. It works well in mobile devices, televisions, and assistive technologies that didn't even exist back then. The same cannot be said of the new Space Jam website. Definitely check out that talk for a deep dive into what the difference is and why the original website is so versatile today.  I call this case-by-case web design. It's very common, and it's baked into how many people think about responsive design, forms, and accessibility. But a better way to build products on the web is to find universal ways to build things. For example, if you want to respond to click events, you could create a div and add click handlers. To make it work with a keyboard, you could add a tab index and handle focus. To make it work on mobile, you could learn about under what conditions mobile browsers send emulated mouse events. On televisions, you could research how different televisions communicate the action button and handle that, and you could investigate how to communicate that the div is clickable to assistive technologies, or you could use a button. You see, every web browser has a fundamental behavior called the activation behavior, and it happens when someone activates a button according to their operating system. So on a desktop browser, that means clicking a button, of course. While on a mobile browser, it means tapping the button. On a television, that means pressing the center button on your remote. On Xbox for Edge, it's the A button. And for users using assistive technologies, buttons just work. And on all platforms, if there is a gesture to go to the next interactive element, the gesture will bring you to the button, ready to be activated. So you can think of buttons as general purpose labeled actions that you can navigate to, and the click event as the activate event. Oh, and you can style buttons however you want. This may not have been true in the past, but today you can style a button just as effectively as you style the div. This all sounds very abstract, and I'm sure that for many of you, this discussion has made your eyes glaze over. But that's the point. If you have some content in your web app, and you want the user to be able to take an action by activating it, you have a button. Don't add a click handler to your div or image. Turn it into a button, and it will work everywhere. This general principle applies to more than just buttons. If you want a place for the user to enter some text, use an input field and the input event. And it will work on desktops and laptops, of course, but it will also work on mobile devices with virtual keyboards, VR headsets with pointer style keyboards, televisions with keyboards on an attached phone, users using assistive technologies, and who knows, maybe a neural interface someday. If you use a key down or key press event instead, you end up with the thing that happens when banks try to get clever with their events, and you can't use a password manager to enter your password or credit card. I hate that. Even on desktops, there are ways to get text into input fields other than pressing those specific keys. You can hit control or command V. If you want to get text, you can use a password manager or auto-filling extension. There are even more ways to get text into an input field than mobile devices, and of course, there are also assistive technologies. If you want the universal answer to the question, use the input event, and it will work with all those cases, and you can forget all the weird stuff I just told you. All you need to remember is this. Key press is pretty hard coded to specific situations involving a hardware keyboard, so don't use it. One more example. We tend to think we know what colors look and feel like but there's a lot we tend to forget. First of all, almost nobody calibrates their monitors and the differences can be huge. This is why web developers don't calibrate their monitors and print designers do. There's no point in getting super precise colors if your users have wildly different monitors. Then there's Night Mode, which is increasingly popular on mobile phones and desktops. Night Mode radically changes the ratios of red, green, and blue on purpose. And Android now ships standard with a feature that will actually put your phone into black and white mode at night. One in 12 men and one in 200 women has some form of color blindness. And on top of that, different cultures interpret colors differently. I'm not saying don't use color in your applications, but if you want to design your web app for a universal audience, you should make sure it looks good in black and white. There are two awesome talks about color, contrast, and night mode, and I really recommend you check them out to get more information. In summary, when building web applications, it's important for us to try to get outside and disconnect from our own faculties. It's sort of a spiritual thing, I guess, but it's important to remember that the vast majority of our users look nothing like us. It's not that accessibility, televisions, or mobile devices are a special case. It's that each of us is an extremely special case. And building for a more universal sense of our users creates better products for them. Over the past few years, Melanie Sumner has been working to make products built with Ember more universal by design. The accessibility community has done incredible work to define what universal design means, so a lot of the work has been focused on helping Ember apps meet the guidelines established by the accessibility community. The first goal was, make sure new Ember apps satisfy these guidelines out of the box. There was some work to do here, and this effort led directly to a feature that everyone can benefit from, Ember new dash dash interactive. But what happens after you generate the app? How can Ember apps remain as universal as possible? App developers already have a lot to do, and it wouldn't work for us to ask every Ember developer to keep all these rules in their head at all times on top of everything else they already need to do. Instead, we started to provide automated guidance through linting and testing facilities. And I don't just mean the classic image-to-have-and-alt tag that everyone demos, I mean stuff like linting against adding a click handler to a div for the reasons we discussed earlier. It lints against duplicate landmarks, empty headings, headings inside of buttons, and way more. By the way, Chris Manson has a great talk on how to use the lint to the future add-on to adopt linting rules like this in an existing code base incrementally. Making it easy for Ember applications to use universal design principles is a key area of focus of Polaris, and the accessibility working group deserves a ton of credit for their hard work and determination. Some day, I expect to stand here and talk about how idiomatic Ember apps naturally work on every device that has a web browser. If you're excited by that vision, you can help make that happen. If you're interested, please find Melanie. There's lots to do. Whew, that was quite the whirlwind tour. Two recap. Embers is a framework for building long-term products together with others. That means that when we design the future we want to live in, we don't just design the future, we make sure that the present can live side by side with the future and we build a bridge for everyone to cross. Octane was an incredible example of how far we can push that vision. We went from classic classes, classic components, and a classic reactivity system to native classes, glimmer components, and the auto-tracking reactivity system. Not to mention going from app.import to NPM packages. And we made sure that those new features interoperated with the classic versions of those features. In practice, people were able to migrate a little at a time and build new features with Octane idioms right away. And we're following that same path with Polaris. Polaris will include more reactive data structures, template tag, support for ecosystem bundlers, automatic route-based code splitting, built-in TypeScript support, and the foundation of a new core pillar of the Ember framework universal design. That sounds like a lot, but the truth is we've already built a great deal of that future. You can even use much of it today. But to finish the job and ship Polaris, we need to build a bridge from Octane to Polaris. We need to ensure that all of these new world features interoperate so well with the apps you're writing today that you can use them right away in new code and migrate existing code over time. If there's one thing the Ember community knows how to do, it's building the future that we want and making sure that we all end up there. It's not the most glamorous thing in the world, but we sure make some amazing apps and our users love us for it. And with that, I'm going to hand it off to Godfrey who's going to give a more technical update on many of the same themes. Take it away.


Every single week we do the great search brought to you by digikey. Thank you digikey for helping us do this show and so much more We got a question on one of our last Great searches from Aaron. We know everyone about girl and Aaron says What would you recommend for part selection when it has less than a hundred stock? How can you tell if the part is being discontinued or just waiting more to come in really like the series find a super valuable to Learn these tips and tricks keep it up We need a okay answer We're gonna cover that today because Coincidentally, maybe the part that I'm going to be searching for isn't in stock And so let's see how to well first off. We'll find some alternatives But we'll also see to figure out is this part ever coming back in stock You know, you don't always know right sometimes parts are discontinued I'll give you some some tips and also how to tell when it's gonna come back in stock Used to be a little easier find out did you keep but you could still find that information if you're sneaky So let's do this thing Okay, so we're going to get a can bus transceiver for the sam e 51 featherboard that I've designed The sam e 51 is a three point three volt microcontroller can bus is really ancient It's like midi ish. It's like this very old simple, but very popular and effective Industrial protocol for sending and receiving messages. There's like extended versions. There's like high speed versions. What not? But basically it uses a five volt differential signals I'm still not 100% sure why sometimes you can get away with three volt differential signals But it seems like everybody kind of wants especially if you're doing automotive you really want to do Plus or minus five volts That said your right controller is gonna be three volts So it's one of those like three volt data, but then out here. It's five volt data So you want a chip that can kind of handle both, you know, like peanut butter and jelly go great together Three of all one side five volt on the other keep them safe, but also have that nice big differential voltage so you can Was sending received messages even in very noisy situations like in a car so the first thing I do when I want to spec a part that goes with another part is I actually look at the eval board because The eval board now first off your it's not unusual the eval board is going to use parts that are from that company So it's not necessarily always the best part, but it's at least a part that you know is going to work So in this case you go to your microchip site They have for this chip the same E 54 explained pro the same E 54 is like even better than the same E 51 But yes ethernet, but basically it's the same chip just has this extra peripheral and in documents you can download the user guide which I did and The one of the most frustrating things that can is like searching for the word can is very difficult because the word can is used in English a lot however You get eventually to this section where they talk about it and they say okay It's connected to an ATA 65 61 physical layer transceiver That's the thing that converts the you know RX and TX three-volt signal to the plus or minus five volts like it's like Dominant recessive or something. There's some wording that they use So this is their chip. So again not too surprising This interface controller is From the same company that's that's not a bad thing. I mean, I'm not against it I sometimes mix and match in a design, but there's nothing wrong with also just going with the supplier themselves and then in These documents you can look at the data sheet high speed can transceiver communication speed up to five megabits per second one thing that you'll want to Oh, I don't think I have the Sam E 51 data sheet open Hold on I've got but the Sam E 51 data sheet implies that the Canvas controller is it can do like a one megabit per second or it can do up to 10 megabit per second So it's I think you can do quite high speeds So that's something. Oh Yeah, wait, so this is the This is a day sheet. I did have it open Yes, if you find the can bus controller it can do can fd which If you like search through 2000 pages, it does say somewhere like oh, it can do up to like 10 megabit and This transceiver can do up to five megabit So that means it's just like okay If you're if you're gonna find an equivalent one you'll want to have it about that speed capability The other thing that you'll see is basically the voltage So the the protective voltage input like how much voltage it can handle before failure It's usually like 60 to 70 volts depending on your You know industrial requirements that might be important to you there's two package types these tend to come in SOIC and There's two very similar, but not quite the same Pinouts, so you'll notice that they have TX and Ground and VCC and RX and then stand by can H. Cannell and then this one has like Not used. I don't know what and sale is and this has via. Oh Via. Oh is on this sixty five sixty one and that is the version That can handle Three to five volts Logic, so that's what you want. We want the one. That's the sixty five sixty one So you have to be careful sometimes part numbers. They're shared in the same data sheet, but that doesn't mean they're equivalent This one in particular. We definitely only want the ATA sixty five sixty one, so Knowing that let's go back did you key? Don't forget to sign up and get some ESP 32 S2 chips the FR-01 and the FH chip that just came out and then in transceivers We can see Yay, there's transceivers. There's the ATA sixty five sixty one. That's what we wanted. However Some bad news this version the DFN the small chip version is in stock you can see by mousing over it's got little it's like teeny doesn't have the pin sticking out and My design is kind of already done and it's for SOIC So let's go go here. Okay. Well, you know, we can look for an equivalent Maybe I'll show an equivalent how to do that really quickly, but you'll see there's zero in stock and like You know, I'm impatient especially here's another thing to watch out for you See this the manufacturer lead time 30 weeks now right now at this moment in time Every manufacturer is having like totally nutty lead times because all over Asia There's like lockdowns and my factories aren't open and like things are very like difficult to do Do due to like government restrictions for COVID-19? however Just because it says that that's like the worst case if you said I need a billion chips How long will it take you? They're like, well, we'll get to you in 30 weeks That doesn't mean it's gonna take 30 weeks for it to be in stock. So like watch out for that. It's it's the max The min max, right? It's like the worst case So here's what we do now It used to be visible here and it's not but what you can do is you can put like a thousand or a hundred in stock You add your cart and I already had I already had some in cart so it can Change just 100 and then you see here oops Sorry, I do look it it says here It's a back order and then there's this little thing here that says checkly time. That's the sneaky thing So click that and it will tell you When they're expected to be in so they're expected to be in stock around The end of the year now, that's also very It's often quite true. I found that the lead times are a good guideline Unless there's some like catastrophe that occurs if they say that they're gonna have a shipment to digikey on 1231 they're probably gonna get it to them at around 1231 so I wouldn't like Bet my manufacturing line on it like if I absolutely needed to have it You know the next day I wouldn't Trust this because you know it can vary there can be shipping delays or can be a storm However, you know, it just means like will is ever be in stock again. Yes in a couple weeks So that's a good thing for me to know if I'm thinking about using this in my design When I can get more so I actually use that tool all the time Like I'll put stuff in stock that isn't in stock into my cart just to get an idea of like How long does it take for this to get back into stock? So I'm not so I can like kind of plan out my manufacturing runs like if I have a sensor I want to get and It's out of stock because it's everyone bought it up one of the one of they're gonna be more I can do that and I can say like oh, you know I don't have to rush my PCB design because I'm not gonna be in stock until at least, you know late December for example So that's said don't forget if you want to get an equivalent part you can always go down to the product attributes and then Click the things that you want to match up and you know, don't be too picky, but be specific enough that you can Get the item you want so you want to be an active Can transceiver with one rx and one tx. We want that same pinout The voltage supply and temperature. I'm not gonna click for reasons. However, I do want it to be the same package and Then there's only 40 remaining similar. So that's actually kind of nice. It means I can Pick out which ones now that AT 6561 was 5 megabit per second So I might want to select that and then the voltage supplies again Those are don't don't believe those Because again, there's the the voltage supply of the can transceiver, which is about five volts And then there's the reference voltage that you'll use for sending data back and forth and then So you will have to look at the data sheet and then I want the ones only that are in stock and Then it looks like there's a couple options I can get from maybe the TJ 1044 I can also be Less picky about some of these things like if I want to For example instead of protocol I'll tell you why there's Ken. There's Ken. Oh interesting. They selected multiple. There's Ken and there's Ken bus, which like I wish they would be merged together, but they're actually two separate categories for the same thing and Then I can you know sort by price or I can sort down by stock to see which ones have the most Stocks there's like a lot of of like these transceivers that the TJ or Whatever 1050 ones those are basically equivalent and that's actually ended up what I used on my design one thing that I Have started to do I prefer not to buy from marketplace. I want stuff to come directly to me from digikey And Rochester it ships from digikey So if you want it to ship at the digikey speed like the way I don't I'm picky about that You can unclick the marketplace products and then you know like this Transceiver is a high-speed transceiver. This one's from nxp instead You know obviously microchip wouldn't use this on their dev board because we're gonna use microchip however, when you go down to the specifications and The pinout You'll see it's like exactly the same So this pinout is what is this exactly same? Yeah, TX TX ground VCC RX TX ground VCC RX And then stand by Stand by high low VIO stand by high low VIO so you can you can use this basically as an equivalent drop-in replacement There's a lot of transceivers To pick the one that has basically the the safety margins you need But you know what I'll probably do is come with a list of a good three or four of these that are equivalent And that way as I'm going to manufacture if one is out of stock like that AT You know a TA series I can always sub in a TGA 1051 instead very wise always tell people when they're designing to have multiple sources for chips I have seen many companies Not bankrupt but get very close because they are waiting for a chip that they couldn't get and they were out of stock for months and months And months you don't want that to happen to you I'm making kill you because if you don't if you have all but one part to manufacture you have nothing That's my wisdom for the day. Oh, we make sure you have a backup plan for parts. All right, and that's our this week's research. Yes


Welcome back to JSA TV Live. We are the telecom and data center news source, and we're coming to you live from the channel partners, the Expo Hall, wrapping up day two, and we have the wonderful Allison Wheeling here. She's been the star of the show behind the camera. So thank you for all of your hard work to help bring us these JSA TV lives. Having so much fun. I get to chat with everybody a little bit before they get their interviews started. And I think we need to talk about our location for a minute because we're right outside the Expo floor entrance. We're right next to the CP Expo sign where everyone's coming to take photos, lots of foot traffic. So I feel like we couldn't have a better location. We get to see everybody, get lots of waves here and there, get a lot of small talk. So it's been great. And it's Kili's first channel partners actually. So Kili, what did you think of the event so far? It's been so amazing. I have heard nothing but wonderful things prior to coming here. And it did not disappoint the Expo floor, the showroom floor is just so well done. There's a lot of really cool things to do in there. I think it has to be one of the top Expo floors. I mean, the booths are so intricate, the giveaways, there's more food and drinks than you could need. It's basically a food court these days on the Expo floor. So if you're hungry, head to the Expo floor and you'll probably need another suitcase for all this swag that you'll bring home. I know, I did have to turn down some things because of the limited suitcase space, but I'm blown away. The team that puts on the show is top notch. They have really delivered and everybody who's been here has been so nice. I've heard from everybody that I've talked to that the channel is a giant extended family. And that's really come through strong and now I get to be part of that family. And so are you? Yeah, of course, of course. Yeah, so we heard some really great interviews today from several of our clients. We heard from some folks like Dark Points just shouting out a few, Zenlayer, Net Number, Vertec and Volta. And then of course we had a lot of great interviews yesterday and more to come tomorrow. But before that, there's some fun things happening tonight. There are. So one thing about channel partners, there's lots of events within the event and events late night after parties. So there's two big ones tonight. Avant is having their event at Tau Beach tonight. And then IntelliSys is heading over to Aria and Jewel Nightclub. We've been to both. Both are absolutely amazing events.  You do need those wristbands to get in. So don't get stopped at the door. Make sure that you can enjoy the long night that's ahead of all of us. That's right. Okay. Well, we will sign off for now, but don't forget to tune back in tomorrow for JSA TV lives. We'll bring you day three from channel partners or day three of our podcast from channel partners. Yes. And then we'll close up shop and do it all again next year. We'll see you all tomorrow at 10 a.m. Hi. Happy networking.