 Okay, so hi, I'm Natasha Wolfe, and I'm an engineer at Audit Board, which is an audit risk and compliance software. Today I want to share my learning journey and getting involved for the first time. My learning journey began as a hairstylist, I'm a client of mine, sorry, let me just mute Slack real quick. A client of mine, Dave Laird, came in for a haircut before giving a talk about coding bootcamps. And I remember asking him, are those legit? And he said something like, absolutely, I taught myself to code 20 years ago, you don't have to have a computer science degree. I had heard about coding bootcamps and I was interested in them, but I kind of thought they were a scam honestly. So I began asking other clients in the industry, have you hired from bootcamps before? What was your experience with people coming in from bootcamps and would you hire again? After a few months I decided to take the plunge and I remember when I put in my notice my manager asked, don't you have to be really smart to do that? After I completed the bootcamp I reached out to Dave who sparked my career change and asked for advice on being a new dev, what to study and any tips for applying to jobs. I was looking back at this message I sent to Dave and it was exactly three years ago today. So must be fate that brought me here today. I can't thank Dave enough for the impact he's made on my career, I could cry. He's the reason I learned to code and learned Ember and he's no longer my client but he's also my friend and mentor and co-worker. As a newbie to the industry I found similarities between being an apprentice hairstylist and a junior developer. Both are crafts that require continuous learning where the more that you learn the more you realize you still have so much more to learn. After hair school I was an apprentice at the salon and being an apprentice your first few months is basically sweeping, shampooing and blow drying. When you're not helping out other stylists you should shadow and work on mannequins and all of your downtime. Being a junior dev is similar to being an apprentice. Practicing on a mannequin is like practicing a new skill or a tool maybe through a tutorial. A shadowing senior stylist is like pairing with senior devs. Sweeping the floors is like refactoring old code. I had begun learning Ember about four months before my interview with audit board and Octane had just been released. I started practicing on my mannequin with the Ember guide tutorial super rentals and Thompson and Zoe had me feeling very confident. I was beginning to see why Ember is a framework people like. Then I went on to rock and roll with Ember Octane and things got more difficult. I broke the app at least 10 times and had to start from the beginning but each failed attempt to help solidify my understanding. When I started to audit board I was working on bugs and refactoring old code. One of my tasks was to update global route action helpers to use actions defined on a service. While there I would update the pre Octane Ember component into a glimmer component. In some ways these first tasks were sweeping the floors. It was difficult coming to such a large code base which was mostly pre glimmer. This was challenging to understand previous patterns. Even little things were confusing like where arguments were coming from. Looking back to my questions to other devs a big thing was struggling with writing tests. We have complex models and understanding them and their relationships was the most difficult part of writing them. My first PR was as terrifying as my first haircut. My friend Gina was a model a month into hair school and I'll never forget how nervous we both were. Thankfully we're still friends so I think it went okay. After submitting my first PR I had 11 comments on 99 lines of code but those are my favorite PR reviews. Give me all the feedback. I want to know what to avoid and how to write better code. When it came to my first future work at the time I didn't know this but I had a tool for my hairstylist days that would be really handy. The key to any great haircut or color is the consultation. When you start a service you're asking questions to understand your client's problems and their goals. Their maintenance schedule when will they be back in for a haircut or color? How do they style their hair at home? You gather details before you ever touch their hair with scissors or go from formulate a color. As a hairstylist consultations were obvious. You can't just give somebody a bob without knowing that they want shorter hair. But as a new dev it wasn't obvious that every feature and every ticket I needed to run through my own consultation. So when I reached out to a senior dub for help beginning my first future work he asked questions about the ticket and the design that I didn't know how to answer. I didn't even think to ask. So once we got those answers he helped me get the route in the template set up and he gave me some tips on how to break down the overall feature and create a plan. Took time to develop these skills and I'm still working on them. But really this isn't far off from how I began every appointment at the salon. Anyways, so here's what I learned while prepping for today and trying to get involved for the first time. When I asked chat GTP to explain in our data to me as if I were a 10 year old aspiring hairstylist. It basically said imagine that you have a friend who is a hairstylist who has a toolbox of hair magic. Ember data is like a magic helper that keeps track of hairstylists and their favorite tools. It can save properties for the tools like the brand size and color. It can keep everything organized so that the hairstylist can quickly find the right tools when they need it. It can update their tools when they get new ones or replace old tools. Ember data is like a magical assistant that hairstylists rely on to remember and manage their favorite tools. It ensures that everything is in order and makes it easier for them to create amazing hairstyles for their clients. And I think that's a nice visual way to think about how ember data can be useful. Looking back over the history of ember and what was solved with octane, the first ember meetup in Seattle was in December of 2012. I guess it's also a good thing to note that I live in Seattle, which is why I'm talking about Seattle. At the time, I heard that the, or at the event, I heard that the Margarita machine was amazing and that it was at the Avalara office overlooking the Seattle waterfront. Jake Bixby, the inspiration of the Seattle Tomster mascot, and Dave were there. The Kiwi that got me into ember got himself into ember at that exact meetup, and it was all because of ember data. At that time, ember had a lot of tools to help out where JavaScript was lacking, like promises and classes. So part of the evolution of ember leading up to octane was just due to the web changing and JavaScript evolving. In octane, one big piece was improving the glimmer reactivity system and rendering faster. While learning about the history of ember, I also learned that in the history of audit board, we have a version of data tables that use jQuery because the previous template engine wasn't fast enough. Octane helped us improve and expand on a new version of data tables that's much faster, and we no longer need jQuery. To me, learning about why that data table used jQuery helped me understand some of the design decisions that were made at audit board. Ultimately, because of the improvements of octane, it really opened up the opportunity to improve ember data. The key improvement from octane that enabled ember data's significant changes is tracked properties. This is because computed properties extended ember object. This meant that it was ember specific inside of the ember framework. While ember data has always been its own package, it could never be used without an ember app. With tracked and cached decorators, it became possible to no longer be ember specific. It's vanilla JavaScript that has bindings used in tracked and cached to put them into the reactivity system. With the future leading up to Polaris, ember data is being broken out into multiple packages. This enables any JavaScript application to use what they need, whether it be ember data request or ember data store. You can see these changes in the evolving in the docs as packages are being broken out of ember data. So we know track properties are great, but it's still difficult when you're maintaining bindings for reactivity in multiple frameworks as ember data can now be used in any JavaScript application. This is where Starbeam comes in to solve for universal reactivity. Starbeam can be used in any JavaScript application using reactive values along with vanilla JavaScript features, such as methods and getters. You now have the data how and when you need it. Ember data will have a lot of other big improvements, such as documents. A document is returned by an ember data request. It includes the resources you fetch, links for pagination, meta information, and an error object. The document can have different perspectives of that request on the same page. Pagination links returned by the document provide the ability to have first, next, last, and previous, which is so cool. The document itself will be cached using a new type of unique identifier, the URL. This will prevent over-fetching. As you know, you will have the data that you need for that view. And you will only hit Network when that URL has not been fetched before. Since the URL will be used, it can store things like ordering, sorting, and filtering. Along with the URL, the cache is evolving to allow for forking. Forks provide an easy way to hold dirty attributes and can be discarded, rolling back the changes, or save, or you can save the changes. I'm so excited to see how these changes in Polaris, some of which can be used now, are going to impact our application at Audible. We over-fetch all over the app because it's difficult to be sure that we have all the data we need, partially because it's difficult to fully trust the cache, so we ended up reloading the data. Caching the URL, being confident we have the data we need, combined with pagination links, performance-wise, is a huge one for us. It's a little video that should play, OK. So we'll take a peek at how caching the URL in the document returned by the request service come into play. And we'll pay close attention to the requests that are being fired off. And at the last request, we can see there's a couple query prams, title ascending, publication date ascending. And as we add filters to that center list, like the author Stephen King, we'll see another network request fire off. When we add a genre for mystery, we'll see the same. But as we remove those filters, we won't see it hit network again because the URL's already been cached. When we look at the document, being returned by the request, we can see our collection of resources or books in this case and our links for pagination. As we visit these links, we will start to see the next and previous links come into view. And when we revisit the links that we've already visited before, you will see that we don't hit the network again. So that's a nice little preview of how documents and caching can work together. Be sure to catch or inspire tomorrow morning. Dive deeper into Ember data. What was it like getting involved for the first time? Well, I expected to read RFCs, EDDs, and previous documentation and other acronym things, and that I would be able to help write guides easily. But what actually happened is that I read those and read them again. And I didn't have enough understanding to be able to write about it. Contributing for the first time is happening slower than I wanted to become an expert in three months. Turns out, two years into using Ember, learning is still hard. But I've learned a lot along the way, and I'm excited to continue to learn more while sweeping the floors. My first update to the API guides was for many array. So specifically, mutation and managing verses. This was a bit of an aha moment for me, so maybe it'll be for some of you too. Here's what helped me make sense of inverses. Let's imagine that we have two hairstylist hamsters, I mean, Nomster and Chloe, and one favorite tool, scissors. Each hairstylist has an array of their favorite tools. In setup one, we define a hairstylist model and we set an inverse for a has many relationship for favorite tools, and we define a tool model with the belongs to hairstylist. Updates made to either resource when we reflected in the other. So, when we give the scissors to Chloe, the scissors no longer belong to Nomster and they're not a part of his favorite tools. Now the scissors belong to Chloe and they're part of her favorite tools. In setup two, we remove the belongs to relationship on the tool model. When an inverse is not defined, Ember creates what's essentially an implicit relationship so that it has a pointer if you destroy a record to destroy the pointer on the related records, which makes sense so that you don't get an error for fetching favorite tools that have already been replaced. However, when we give the scissors to Chloe, the scissors still belong to Nomster, but the scissors are now included in both Zoe and Nomster's, Chloe and Nomster's favorite tools. Makes sense, right? We're on the same page. This is actual footage of Runspire breaking down inverses to me. In setup three, we set the inverse to null on both the has many and belongs to your relationship. So, just like before, when we give the scissors to Chloe, the scissors will still belong to Nomster but are included in both Chloe and Nomster's favorite tools. But, if we didn't push the scissors to Chloe, but instead we assign Chloe as the scissors hairstylist, then the scissors would belong to Zoe, Chloe, and the scissors would belong to Nomster. But Chloe's favorite tools will not include the scissors. However, the scissors would still be a part of Nomster's favorite tools. This example helped me understand how manage inverses helps maintain data consistency and simplifies managing relationships between models. What was easy about contributing, getting involved? I'm really fortunate to work at Audiford. We have a few Ember core team members and a lot of talented engineers, so I'm fortunate to have a lot of resources nearby. I love learning and there's a lot of really cool things coming with Ember and Ember data, so it's really fun to dive in and learn more. Starting small, documentation's a great first way to get involved. In Yehuda's keynote 2021 talk, he mentioned that Quest had become a thing and that the Ember community rallied to complete the Quest, who wouldn't want to be a part of that community. While preparing for this talk, I've had a few conversations about what I've learned and it sparked history chats about Ember, Audiford and JavaScript, which is just a fun added bonus I didn't expect. But the easiest part of all is that someone believed that I could actually be helpful and I think that we all doubt that sometimes, especially as newbies and it takes a bit of encouragement to do things that you wouldn't otherwise. So thanks, Chris. What was hard? Contributing proved to be a learning experience in itself, being prepared to be confused and uncomfortable, again, two years in. This is how the human brain learns best, being confused helps us remember what we're learning. General lack of context to Ember, Ember data, JavaScript fundamentals, also is challenging. Having to get guidance to even understand things like why would you need multiple handlers? I wrote that in my notes several times while reading an RFC. The amount of time to gain context has slowed me down, but knowing that it'll pay dividends in my careers in the long run is encouraging to continue. At Audiford, we've been having meetings around how we're gonna implement new things coming with Ember data. At the first meeting, it was very over my head and I had no idea of what was being discussed. But by the next meeting, I had read a few RFCs and was able to follow along and understand so much more than the first meeting. So how can you get involved for the first time? Contributing to Ember and Ember data is open to anyone, regardless of experience level. There's opportunities for small contributions, such as documentation like me, or implementing new features. I heard about this this morning as well, but joining the new contributors and Discord would also be a great place to start. Exploring good first issue, good for new contributor tags and Ember data repository are excellent ways to get started. Get involved in the RFC process, asking questions and giving your perspective. As a newbie, we can doubt that our questions are relevant, but I've been learning that our newbies' perspective is special. Once someone has too much context, they need us to be able to understand where the gaps are, even if it is just for documentation. Maybe reach out to the person who wrote the issue on Discord. Engaging with the Ember community and joining Discord don't be like me and wait to meet people in person in EmberConf before joining in with the community. Say hi to me on one of these platforms. Thanks for the opportunity to be up here, you guys.