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. Okay. A client of mine, Dave came in for a haircut

before giving a talk about coding boot camps. 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 boot camps, 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 boot camps before? What was your experience with people coming in from boot camps, 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 boot camp, 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 coworker. Thanks. 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 trying. 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. Shadowing senior stylists is like pairing with senior devs. Sweeping the floors is like refactoring old

code. I'd begun learning Ember about four months before my interview with Auditboard, and Octane had just been released. I started practicing on my mannequin with the Ember Guides tutorial Super Rentals, and Tomster 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 ten times and had to start from the beginning, but each failed attempt helped solidify my understanding. When I started at Auditboard, 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 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 dev 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 and 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 ChatGTP to explain Ember Data to me as if I were a 10-year-old aspiring hairstylist, it basically said, imagine that you have a friend who's 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 hop 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 templating 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 as 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 evolving in the docs as packages are being broken out of Ember Data. So, we know tracked 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'll 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

on audit board. 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 win for us.

This is a little video that should play. Okay. So we'll take a peek at how caching the URL and 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 is sending. Publication date is sending. 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 has 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 won't you will see that we don't hit network again. So that's a

nice little preview of how documents and caching can work together. Be sure to catch our 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, you know, 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 from mini array, specifically mutation and manage inverses. 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, Tomster, 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 a belongs to hairstylist. Updates made to either resource will be 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 Chloe and Nomster's favorite tools. Makes sense, right? We're on the same page. This is actual footage of run spired 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

Autocord. 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, Autocord, 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 Autopboard, we've been having meetings around how we're going to implement new things coming with Ember data. At the first meeting, it was very over my head and

I had no idea 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, that joining the new contributors in 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 newbie's 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 at 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.