Introducing the Vue 3 and XState kit for starter.dev
*Starter.dev is an open source community resource developed by This Dot Labs that provides code starter kits in a variety of web technologies, including React, Angular, Vue, etc. with the hope of enabling developers to bootstrap their projects quickly without having to spend time configuring tooling.* Intro Today, we’re delighted to announce a new starter kit featuring Vue and XState! In this blog post, we’ll dive into what’s included with the kit, how to get started using it, and what makes this kit unique. What’s included All of our kits strive to provide you with popular and reliable frameworks and libraries, along with recommended tooling all configured for you, and designed to help you spin your projects up faster. This kit includes: - Vue as the core JS framework - XState for managing our application’s state - CSS for styling - Cypress component testing - Vue Router to manage navigation between pages - Storybook for visual prototyping - ESlint and Prettier to lint and format your code How to get started using the kit To get started using this kit, we recommend the starter CLI tool. You can pass in the kit name directly, and the tool will guide you through naming your project, installing your dependencies, and running the app locally. Each kit comes with some sample components, so you can see how the provided tooling works together right away. ` Now let’s dive into some of the unique aspects of this kit. Vue 3 Vue is a very powerful JS framework. We chose to use Vue directly to highlight some of the features that make it such a joy to work with. One of our favorite features is Vue’s single file components (SFC). We can include our JavaScript, HTML, and CSS for each component all in the same file. This makes it easier to keep all related code directly next to each other, making it easier to debug issues, and allowing less file flipping. Since we’re in Vue 3, we’re also able to make use of the new Composition API, which looks and feels a bit more like vanilla JavaScript. You can import files, create functions, and do most anything you could in regular JavaScript within your component’s script tag. Any variable name you create is automatically available within your HTML template. Provide and Inject Another feature we got to use specifically in this starter kit is the new provide and inject functionality. You can read more details about this in the Vue docs, but this feature gives us a way to avoid prop drilling and provide values directly where they’re needed. In this starter kit, we include a “greeting” example, which makes an API call using a provided message, and shows the user a generated greeting. Initially, we provided this message as a prop through the router to the greeting component. This works, but it did require us to do a little more legwork to provide a fallback value, as well as needing our router to be aware of the prop. Using the provide / inject setup, we’re able to provide our message through the root level of the app, making it globally available to any child component. Then, when we need to use it in our ` component, we inject the “key” we expect (our message), and it provides a built-in way for us to provide a default value to use as a fallback. Now our router doesn’t need to do any prop handling! And our component consistently works with the provided value or offers our default if something goes wrong. ` ` Using XState If you haven’t had a chance to look into XState before, we highly recommend checking out their documentation. They have a great intro to state machines and state charts that explains the concepts really well. One of the biggest mindset shifts that happens when you work with state machines is that they really help you think through how your application should work. State machines make you think explicitly through the different modes or “states” your application can get into, and what actions or side effects should happen in those states. By thinking directly through these, it helps you avoid sneaky edge cases and mutations you don’t expect. Difference between Context and State One of the parts that can be a little confusing at first is the difference between “state” and “context” when it comes to state machines. It can be easy to think of state as any values you store in your application that you want to persist between components or paths, and that can be accurate. However, with XState, a “state” is really more the idea of what configurations your app can be in. A common example is a music player. Your player can be in an “off” state, a “playing” state, or a “paused” state. These are all different modes, if you will, that can happen when your music player is interacted with. They can be values in a way, but they’re really more like the versions of your interface that you want to exist. You can transition between states, but when you go back to a specific state, you expect everything to behave the same way each time. States can trigger changes to your data or make API calls, but each time you enter or leave a state, you should be able to see the same actions occur. They give you stability and help prevent hidden edge cases. Values that we normally think of as state, things like strings or numbers or objects, that might change as your application is interacted with. These are the values that are stored in the “context” within XState. Our context values are the pieces of our application that are quantitative and that we expect will change as our application is working. ` Declaring Actions and Services When we create a state machine with XState, it accepts two values- a config object and an options object. The config tells us what the machine does. This is where we define our states and transitions. In the options object, we can provide more information on how the machine does things, including logic for guards, actions, and effects. You can write your actions and effect logic within the state that initiates those calls, which can be great for getting the machine working in the beginning. However, it’s recommended to make those into named functions within the options object, making it easier to debug issues and improving the readability for how our machine works. Cypress Testing The last interesting thing we’d like to talk about is our setup for using component testing in Cypress! To use their component testing feature, they provide you with a mount command, which handles mounting your individual components onto their test runner so you can unit test them in isolation. While this works great out of the box, there’s also a way to customize the mount command if you need to! This is where you’d want to add any configuration your application needs to work properly in a testing setup. Things like routing and state management setups would get added to this function. Since we made use of Vue’s provide and inject functions, we needed to add the provided value to our ` command in order for our greeting test to properly work. With that set up, we can allow it to provide our default empty string for tests that don’t need to worry about injecting a value (or when we specifically want to test our default value), and then we can inject the value we want in the tests that do need a specific value! ` Conclusion We hope you enjoy using this starter kit! We’ve touched a bit on the benefits of using Vue 3, how XState keeps our application working as we expect, and how we can test our components with Cypress. Have a request or a question about a [starter.dev] project? Reach out in the issues to make your requests or ask us your questions. The project is 100% open sourced so feel free to hop in and code with us!...
Jul 17, 2023
6 mins
Leveling Up Your Work Through Architecture Design and Time Estimation
> This post can be useful for developers at any level! However, it is written mostly for entry-level developers who are starting to transition into a more intermediate role. You’re rocking your first development job. You’re completing tasks, the team loves you, you still have tons of questions but you can get answers and build what you’re asked to build. But you want to keep improving your skills and giving yourself more options. Some of that skill can only come from actually building things over time. But surely there’s something you can do to level up besides that, right? There is! One way to help deepen your understanding of the software you’re writing and make yourself look more impressive is by improving your ability to estimate your time, and how you talk about your work. That’s what we’re going to dig into today! Some terminology You might have heard of, or have read terms like “software architecture” and “quality attributes” and, upon trying to look into them, been met with a LOT of jargon and dense terminology. So before we get too far into this, let’s go over a few terms we’ll use. (This is by no means meant to be a complete description of these terms. The aim is to be clear enough to continue our discussion here, and let you get started.) - Software architecture: This term means how your system is organized. It’s like the blueprint for the application or website you’re building. How do all the pieces we build fit together and interact with each other? What’s the main goal we’re trying to achieve with this codebase? That’s what this term is talking about. - Software design: Once we have the blueprint, we need to figure out how to build the pieces to make that structure come to life. This is where the design comes in. It’s more code-specific and focuses more on the specifics of what we need to build and how. What languages are we using? How do we get this component to be interactive or usable like we want? This is all the design. - Software quality attributes: Sometimes referred to as “ilities” because a lot of them end with those letters, these are words we use to describe the software we write. Common ones would be accessibility, reliability, or performance. These are words used to describe some of the key qualities we want our software to have. You can start with this list of quality attributes or do a search for “software quality attributes”, and find all sorts of articles covering a lot of the common ones. - Time estimation: This is the skill of being able to consider a task and estimate how long it would take you to complete the task. Time can be a funny thing, and it’s pretty common to think something will be easy and have it take way longer, or think something will be complex, and it turns out to be straightforward. - Trade-offs: This is the idea that two things can’t be equally balanced and/or important. There’s a joke about how people want things fast, cheap, and good and you can’t have all three. This is the same idea. Very often, by increasing one quality, you have to decrease another. The balance of those, and the choice to focus on one quality more than another, is called a trade-off. You’re trading the strength of one quality for another. When we’re using the phrase “architecture design” in this article, we’re combining all these concepts together. How do we get started? Ok, so we’ve got some terms now. But what do we do with them? How do we get better at designing software, and estimating our time? I’ve got two templates to share with you that can help you start to develop these skills. Both will involve writing, but I’ve tried to make them as straightforward to fill out as possible so it’s not a chore to use them. I’ll share links for the templates later on. But first, we’ll go over the actual contents of both of them and talk about how to use them. These templates can be useful for any task, no matter how complex. However, super simple tasks like fixing a broken link on a page, or adjusting a color value to improve its contrast may not be the best choice for it. It is useful to use this template on a task that you fully understand, so you get some practice with thinking about the tradeoffs you’re making, and get used to some of the terminology and how to talk about the software you build. But this can really help when you start getting larger tasks or features- ones that might contain multiple parts working together or some complex logic to get the task working properly. The architecture design template For this template, the goal is to complete this first before you do any work on your task. Use this as a tool to help you think through your work before you get started on it so you can have a better understanding of what the task is asking of you, and let you start thinking about the attributes you’re building for. There are 7 sections for this document, each with a title and description. Let’s go over each piece to see how they work. Big picture: What’s the ask? *What’s the ticket/task trying to solve? What’s the end goal of this body of work? Describe the problem in the most ELI5 way you can.* Use this section to describe the task you’re working on. Act like you’re talking to someone with very little understanding of the situation, like a project manager on another team or to a friend of yours that doesn’t work with you. This section helps you make sure you have a strong handle on the work you’re being asked to do, and what the end result should be. Requirements *Is there acceptance criteria? A specific way it needs to work? What makes this ticket / task count as complete? Steps to reproduce and/or screenshots are helpful here too, if available.* Some of this can often be copied over from the ticket you’re working on. Make note of how you can tell that this task is complete, and any specifics that you need to make sure work as expected when you’re ready to have someone review it. Constraints *Are there specific things you can / can’t use? Something you have to make sure doesn’t break? Tools you have to use because of where you have to work in the codebase?* Making note of constraints can be super helpful. Maybe you have to use a specific UI library to complete this because the rest of the project uses it. Or perhaps this task has been attempted before, and you don’t want to repeat a version that didn’t work. Getting used to thinking about the constraints you’re working within can help prep your brain to think around these concepts. Architecture and Tradeoffs *Where does this code live? (login, ui, db, etc) What software quality attributes are we focused on for this task? List out the primary and secondary attributes (maybe a third if it feels necessary).* In this section, we’re focusing on developing our architecture and design skills in detail. Talk a little about how the codebase is structured, and where the work for this task will be located. Also, pick one or two software quality attributes that you think fit this task. Does the work you’re doing help improve the site’s overall accessibility? Does it make the application more reliable for end users? Does it help to keep our codebase’s maintainability within a reasonable level? Use one of the lists above or your own searches to build out a list of the attributes you might build for regularly, and pick out one or two of them that relate the most to this task. Then, talk a little about why you picked those traits and your thoughts about why they’re applicable. Being able to explain your reasoning here will both help you gain more understanding of the work you’re doing, and the words you’re using to describe it, and give whoever reads this document a better glimpse into the work you do and how you think about it! Initial Gameplan *Considering all the above, what seems like the path forward? What are the steps for how you think it can be solved/completed? Where are you starting?* Now that you’ve spent a little time thinking through the task, and some of the things you should remember about it (like how it’s structured, the tools you have to use, and what’s important to keep in mind while you’re solving it) - write out the steps you think you should take to accomplish the task. It’s perfectly okay to not fully follow this plan as you start to build! We can never fully predict everything that might happen as we start to work in a codebase. The goal here is to give yourself a solid place to start, with all the details we’ve listed fresh in your mind. Process Notes *As you solve this - keep this area updated with rough notes. What did you try that didn’t work? Why not? If you have to pivot, what did you switch to and why? Maybe something worked but you still pivoted - what tradeoffs were made, and what’s the reasoning behind it?* As the description implies, this space is all for you. Try to keep notes as you go. If you do have to change course from your game plan, why and what did you change? Did you find another problem you didn’t even know existed? Or maybe you were able to try a new concept out and it worked! Celebrate your process here. None of this needs to be in complete sentences or easy for anyone but you to understand. This space is all yours to help you keep thinking through the work as you’re doing it! Final Solution *You did it! Form a narrative. Now that you’ve got the issue solved, what does it look like? How did you do it? What did you learn along the way? Is the final solution the same as what you thought, or did the ask pivot along the way? Share screenshots if available.* The final wrap-up! Try to write this similarly to how you started with the big picture. Did your initial plan end up working, and if not why? Were there any interesting plot twists throughout the process? Share the wins, the struggles, and the end result here. Screenshots can be perfect here to see a visual of your work! I also typically leave a little space at the bottom to wrap up any lessons I learned for myself, and leave a little room to talk about my time estimate and reasonings behind how it turned out the way it did. But those are completely optional. --- Because I use a Notion database to help me keep track of these documents, I also have a few properties I can fill out related to the project this document is for, what my time estimate and result were, and the quality attributes I selected. Having those visible at a glance is super helpful for me. The biggest thing I’d recommend to track with this is the date you filled it out. Having that date to help you organize and find your documents is super helpful as your collection grows. I typically title mine based on the project it’s for and the name of the task, but you can name yours whatever you’d like! Now let’s talk about how to track our time for this task. The time estimate template This one is a lot less detailed, but just as important! Being able to improve your knowledge of how long different tasks take you will be a super handy skill as your career continues. The main idea with this template is to keep track of two sections: how long you think something will take you (the estimate), and how long it truly takes you. Our goal is to get those two sections to be as close to the same number as possible. Remember that our goal here is NOT perfection. That’s impossible to reach. Our goal is simply to get them to be close to each other. Most people (even managers) understand that an estimate is not a guarantee. But the closer you can get your estimates to the true time it takes you, the more reliable you seem and the more accurately your team can make progress. There are three main sections to this template. The actual numbers Most importantly, we want an estimated total time and an actual total time, as well as a calculation of the difference between those two numbers. Is our estimate higher, or is the actual total time higher? That difference is what we’re trying to keep as close to zero as possible. I like to break my time tracking down into categories, so I can also see if particular parts of my work take me longer (or shorter) than I think. For each of these, I do the same thing: make an estimate, and record the actual value. The categories I like to track are: Investigation: time to fill out my architecture design, do a little looking into the task, make sure I understand fully what I’m being asked to do, and that I have all the information I need to complete it. Coding: time to do the actual work. Most of my time calculation goes into this category. Testing: I use this for either writing actual unit or end-to-end tests, or for manual testing. This is where I double-check to make sure I didn’t break anything or track time spent on that one last piece of functionality that doesn’t quite work right. Review: any feedback I get on my Pull Requests or code reviews that require me to make changes go into this category. Space to record the numbers as I go The Pomodoro technique works really well for me with time tracking, though I change up my “working time” numbers to make them easier for me to calculate. I’ve found the most straight forward way for me to do this is to have a title for each section of time that I’m tracking, with space underneath each one. Then, I have a legend of colored dot emojis related to a different amount of time: 15 minutes, 30 minutes, and 60 minutes. Then, as I do my rounds of working time, each time I’m done with a round, I select the right colored dot for the amount of time I did, copy it, and paste it under the section the work I did belongs to. Keep repeating this until the work is complete! Once your task is done, all you need to do is count your dots, and record the total number they represent in your actual time section from above. Here’s a screenshot of what one of my completed sections look like, so you can better see what I mean. From this tracking section, I can quickly see that I spent 15 minutes on both testing and review, and an hour and 45 minutes on coding. If I don’t happen to spend any time on a section (in this instance, I’d done some investigating in a separate ticket, so I already knew the work that needed to be done), I just leave it blank. I have a section at the top of my page for tracking the total number for each category. So I use this area to keep track as I’m doing small rounds of work. Then, when I’m done, I add up each number and put it in the section at the top of the page for that category. Notes I also have a section for notes at the bottom of my document. I keep this area for anything relating to my time tracking. Did something break unexpectedly, causing my estimate to be off? Did I not need a section for some reason? Or did something work way better than I thought it would? Those are the kinds of things worth keeping notes of here. Can you tell why your estimate and actual times were off? Sometimes we simply don’t know, but being able to keep notes on the things we can realize as we’re doing them helps us get better the next time! Tying these together and talking about it with others You can use both of these templates together or on their own, and you’ll gain a great amount of knowledge about your skill level and your growth over time from them! But they can also really shine using them together. While these are great tools for your own personal knowledge and growth, I also highly recommend sharing them with someone else. It’s a great idea to set a goal to be better with estimating your time, and sharing that goal with your manager. Then, you can use the time estimation template to build up some estimates, and share those with your manager. Maybe you have a senior developer on your team that you really respect, and you’d like to get their opinion on the task you’re working on. If you’ve filled out the architecture design for that task, you can share it with them and have a conversation about it. They can potentially provide you with things to consider for your next task, or get you thinking more deeply about the quality attributes you selected, and why they may or may not have been the best fit for your work. The design documents are also great to share with your manager! It’s a great way to show that you’re starting to think about your work on a deeper level and starting to consider the quality and complexity of your work. It can also be helpful reference material for them when promotions and new work becomes available. They’re more likely to think you might be a good pick for the next big thing if you’re already showing them you’re starting to think about things at a higher level! The Notion template links The links for both of these documents as Notion templates are below. Please feel free to duplicate a copy for yourself if you like using Notion, or just take a peek at them to see the actual layout of them and adapt that for whatever tool works best for you. These documents are set up to be used within a Notion database. We won’t cover that in detail here, but the Notion documentation should be able to take care of those details for you (and we have a link to get you started below as well). In general, you can create a database within Notion, and then set a template to use for each new entry. That way, when you go to create a new item, it will automatically pull up these templates for you, so you don’t have to copy and paste them every time! And the fields at the top will be visible when you go to look at your database, which makes it a little nicer to get a quick overview of your documents and the progress you’re making. Now go forth and deepen your knowledge! - Time estimation template - Architecture design template - Notion database templates documentation...
Jan 6, 2023
14 mins
How to Create a Custom Login Command with Cypress, React, & Auth0
Auth0 is a tool for handling user authentication and account management. Cypress is a tool for writing end to end tests for your application. Getting these two technologies to work together can have a few gotchas, especially if your application is set up to have the end to end tests in a separate folder from your frontend code. Today, we’ll go over the steps you’ll need to implement so you can have a custom Cypress command to log in a user, and also let your front end code continue to work safely! --- Setup For this setup, we're making the choice to keep our end to end tests in one folder, and our front end code in a sibling folder. You don't have to do it this way. It's just the choice we've made for this project. So our folder setup has two root level folders, "cypress" and "app": ` --- React Adjustments Auth0 provides a default login form for you to use. We’ll focus on the fact that the forms use web workers to store the user’s access tokens in memory. This helps them keep that access token more secure from attackers. This is important to note for Cypress. But because Cypress does not have a way to interact with that web worker. So we need to be able to detect when our application is running the site through Cypress so we can adjust how we get the access token. We’ll need to update the way our Auth0 form saves that token based on if our app is running normally, or if it’s running through Cypress. To do this, we can add a check to the cacheLocation prop in our Auth0Provider field that wraps around our root app component. app/index.ts ` > Important note if you’re using TypeScript: > If your project is using TypeScript, there will be two more small changes you might need to make. > First, your editor may be yelling at you that it doesn’t know what Cypress means, or that it doesn’t exist on the window interface. So you can make a type file to solve this. src/types/globals.d.ts ` > Then, in the root level tsconfig file, we need to add an option to the compilerOptions section so it knows to look for this file we just made and use it. Then your editor should be happy! :) app/tsconfig.ts ` And that’s all your front end code should need to work! It’ll continue to work as expected when running your app locally or in production. But now when you run your Cypress tests, it’ll store that access token in local storage instead, so we can make use of that within our tests. --- Cypress Adjustments Now we can make our custom login command! Having a custom command for something like logging in a user that might need to be repeated before each step is super helpful. It makes it faster for your tests to get started, and doesn’t need to rely on the exact state of your UI so any UI changes you might make won’t affect this command. There’s a few different things we’ll need to handle here: - Writing the custom command itself - Making an e2e file where we’ll set up this command to run before each test - Updating the Cypress config file to know about the environment variables we’ll need - If you’re using TypeScript, you’ll also need to make a separate “namespace” file and an index file to pull all the pieces together. We’ll start with the meat of the project: making that custom command! I’ll share the whole command first. Then we’ll walk through the different sections individually to cover what’s going on with each part. The Custom Command Cypress automatically sets up a support folder for you, so you’ll likely already find a commands file in there. This will go in that file. If you don’t have it, you can create it! cypress/support/commands.ts ` The first piece to note is line 2. Cypress.Commands.add('loginWithAuth0', (username, password) => {... This is what actually tells Cypress “hey, this is a command you can use”. The name can be anything you want. I’m using “loginWithAuth0”, but you could call it “login” or “kitty” or whatever makes the most sense for your project. Just make sure you know what it means! :) Lines 3-6 are setting our the environment variables that the Auth0 call will use. Then, on line 8, we use Cypress to make the actual request to Auth0 that allows us to log in. For this use case, we’re choosing to login with a username and password, so we tell the call that we’re using the “password” type and send all the necessary environment variables for the call to work. (You can find info on what these values should be from the Auth0 docs.) Then, on lines 20 and 21, we’re starting to deal with the response we get back. If the call was successful, this should contain the information on the test user we just signed in and the access token we need for them. So we extract those values from the body of the response so we can use them. On line 22, we again use Cypress to get the browser’s window, and let us store the user access token. We'll use localStorage for this as seen on line 23. Important note here! Pay extra special attention to the way the string is set up that we’re storing in localStorage on line 24! Auth0 needs the access token to be stored in this specific manner. This is the only way it will find our token! So make sure yours is set up the same way. The rest of the code here is taking the information we got from the Auth0 call and adding it to our new localStorage value. You’ll see that on line 35 we’re parsing the user information so we have access to that, and then setting an expiration on line 40 so the token won’t last forever. And that’s it - our command is set up! Now on to the rest of the things we need to set up so we can actually use it. :) Supporting Files If you have commands that should be run before every test call, you can create an e2e file in your support folder. These are your global imports and functions that will apply to all of your Cypress test files. Here we’ll import our custom commands file and actually call our new command in a beforeEach hook, passing in the test username and password we want to use. cypress/support/e2e.ts ` > TypeScript Note: > To get the typings to work properly for your custom commands, you’ll need to do two things. > First, you’ll want to make a new file called namespace in your “support” folder. Then, you’ll want to declare the Cypress namespace in there, and set up a line for your new custom command so Cypress knows the type for it. (If you originally edited the default Cypress commands file, you’ll also want to go to the bottom of that file and remove the namespace section from it - this is replacing that.) ` > Then in your support folder, create an “index.ts” file and add your commands and namespace imports to it. ` > That should clear up any TypeScript related warnings in your files! The final piece is updating our Cypress configuration file. We need to add all the environment variables we need in here so Cypress is aware of them and we don’t have them hard coded in our files. cypress.config.ts ` Wrap Up With that in place, you should be good to go! Whenever you run your Cypress tests now, you should see that a user is automatically logged in for you so you start on the first page of your app. We hope this helps! If you run into any issues or have questions on anything, please feel free to reach out to us. Leave a comment on this post or ask in our Discord. We’ll be happy to help!...
Nov 18, 2022
6 mins
International Women's Day Recap
International Women's Day Event For this year's International Women's Day, we hosted a live event with Women Techmakers, featuring talks and a panel discussion on this year's topic: progress over perfection. It was a great conversation on what it's like to be a woman in tech, and how you can help yourself and others thrive in our industry. In case you missed it We have the full event on YouTube if you'd like to watch it yourself (which I highly recommend)! Here's a recap of everything that happened. Getting started in DevRel - Pachi Parra Pachi Parra was up first, sharing her journey into DevRel, and tips on how you can get started too! Some highlights include: - Roles that are available - What a day in the life might look like - Her journey into DevRel - What a DevRel professional actually does - things like public speaking, live coding, writing blogs, and giving talks at conferences. Her best tip for getting started? Find the type of content you like doing, and focus on doing that well! In DevRel, it's easy to spread yourself too thin between all the different types of content available, so focus on the one you like most, find a supportive community, and get yourself out there. :) Breathing Fire: Success and Growth as a Technical Woman - Stacy Devino Stacy Devino was up next, providing all kinds of insight into the cycle women go through in their career, as well as tips for each stage of the journey. She opened with an amazing quote: > Assume all women are technical and capable of breathing fire. - Jessie Frazelle Other highlights: - Igniting your world through learning, timing, your network, and leadership. - Staying warm by managing your focus and chores, recording your achievements, maintaining relationships, and researching ideas. - The key to avoiding burnout - keeping a long-term perspective, doing things for yourself, and allocating time for the things you enjoy and the people who support you. Riding the imposter wave to senior - Jessica Janiuk Jessica Janiuk wrapped up our talks today, providing insight into her journey through tech and the ways we can think about imposter syndrome and allowing ourselves to grow. Some highlights from her talk: - A few things to consider: what being "senior" means to companies and to yourself, if you're in the right place, and what you want in your career. - A great diagram of the imposter wave - the balance between our confidence and feeling like an imposter from this post by Ricardo Luevanos. - Considering how often we're comfortable, and that there's an inverse correlation between feeling comfortable and feeling like an imposter (they're opposite each other). - We have two choices: we can let it control us, or use that discomfort as a tool. - Looking back on our growth and realizing that our current lows are higher than our past highs. - Some senior advice: Be authentic, be proud of your work, have good mentors, remember that your work is not your life, and stay uncomfortable. She wrapped up with a brilliant reminder for us all: > You are capable. You are valid. You are important. Please take care of yourself. People care about you. If you're struggling, you're not alone. Panel Discussion We rounded out the day with a panel discussion featuring these accomplished women: - Erica Stanley - Amal Hussein - Deborah Kurata - Katerina Skroumpelou - Jessica Janiuk - Stacy Devino - Jae Bach Hardie - Linda Thompson The conversation flowed naturally, each panelist feeding off of each other's ideas, and we covered some very powerful and helpful tips and reminders for women in today's developer world. Here's a few of my favorite topics or ideas we talked about: What did you learn in the past year? - Have hobbies that don't involve tech. - Learning to let go of your previous tools. - How valuable close personal friends are - people you can trust and rely on. - Listen to yourself, and take time to introspect and evaluate. - Don't over commit! Finding a community and actively contributing to it - Women Techmakers! (Our joint sponsor) - Make use of social media. - "Reach one teach one" - always be willing to share your knowledge, and be the person you needed when you were getting started. - Engage people who align with your goals and values - reach outside your level of age, career scope, experience. - The interconnection between you and your people is not exclusive, it's inclusive! The more expansive your sphere is, the better you are at your job. - Also - we can find community in open source! The way people comment, commit, and support each other within a project counts too. Foundational knowledge vs tooling - Understand what problems you're actually solving and what to reach for, more than worrying about the specific tech stack itself. - This helps you build your own knowledge map, and pick up skills as you grow. - For more senior folks - realize when you've mastered something, and focus on clearing the road for those who come next. - Learning to delegate - if you always do something yourself, you're taking that opportunity away from someone else. - Knowing when to ask for help, and that asking is NOT a weakness or failure! It's a strength to know when you need to ask for help. Find your learning method - Ask multiple people if you need to until you find the answer that clicks for you! Ask why. - Not understanding the answer someone gives you is also not a failure - it's different viewpoints. - Also learn how the people around you learn - so you can help them in the way that best suits them. Communication and collaboration - Have compassion for everyone on your team. - When you collaborate, you get more done. - Being able to communicate and collaborate is a HUGE strength. Don't let anyone make you feel bad for being strong in those! - Being the person who's able to "glue" the team together is foundational to a strong team. Fighting stereotypes - Things that are commended in men and reprimanded in women, and fighting against those biases - Being authentic is the best way to lead your team - don't play into a stereotype you don't fit. - You don't have to sound "nice" or "pleasing" - you're still a strong woman and you're going to be judged a certain way, so don't compromise! - Unpacking all the social conditioning and learning to be comfortable with yourself all the time, in all the situations we find ourselves in. Wrapping Up The entire event was filled with wisdom, laughter, and camaraderie. We're so thankful to the ladies who came to speak with us, and hope to see you at the next one!...
Mar 10, 2022
5 mins
Content Projection in Angular
Imagine yourself at a movie theater. No matter what theater you go to, or what movie you see, you'll notice some very similar things - most notably, the large screen the movie plays on. This screen is an excellent example of a reusable object - it can show any movie projected onto it! The screen doesn't need to know the details of the movie it's playing - all it does is show whatever content is projected onto it. This is a similar idea to how content projection works in web development! Today, we'll go over what content projection looks like and how you can use it to make components that are reusable and less tied to the data they display. We'll be using Angular for these examples, but any framework you'd like to use likely has a way to do this as well! If you'd like to view the source code for these examples, you can check them out in this Stackblitz editor. Single slot projection The simplest way to do content projection is to use a single "slot" or area where we pass data in. Note that you're not limited on what data you pass in - you could provide as much data as you wanted in here. But your component that's handling the content projection uses a single slot for all that data. Using the movie example above, let's create a simple "screen" that will display a random cat GIF, and some "now playing" text with it. For the screen component, the HTML will be very simple - just a section container and a special Angular tag called ng-content. This element acts as a placeholder for the content that will be passed into it, and does not create a DOM element itself. It tells the component that we expect some data in an unknown shape to be shown in it's place. ` Then, in our main app component, we can send this screen the data we want it to show! ` And that's it - our single-screen component will display the GIF and title! Multi-slot projection Sometimes, it can be useful to designate some of the data that gets projected into certain sections of our component. In the previous example, we could have the "Now Playing" text set up almost anywhere - it could be on the top of the screen, the bottom, over the image itself. Even though we're projecting data into our component, we can designate some sections with a particular name, so when we write the content that gets sent to the component, we can tell it where to go. If we wanted to set up our screen so that it always shows the name first and then the image in our component, we would specify the select value on the ng-content tag. If we want one of these tags to be the default value, we can leave its select value empty. ` Then, when we add this tag to our main app, we'll see the data in the order our component says it should show, no matter what order we type it in. ` In conclusion This topic can be as simple or as complex as you need it to. There's tons of great use cases for content projection. You could use it to create reusable layouts, as an expansion toggle wrapper around different lists of data, or to create reusable designed pieces that can take in whatever type of data you'd like. If you're interested in some more complex examples, I'd highly recommend checking out the Angular documentation for this subject. Can you think of other great use cases? Let us know! Demo...
Jan 4, 2022
3 mins
How to Make Your First Pull Request for Hacktoberfest
Leaves are changing color. Pumpkin spice flavors are everywhere. Yards are decorated with skeletons, ghouls, and spiders. It must be October in the US! This means it's also time for Hacktoberfest! What is Hacktoberfest, exactly? Hacktoberfest is a month-long event that celebrates open source software, and encourages everyone to get involved. Whether you participate through creating pull requests for your favorite projects, opening your own project to support from others, hosting an event, or donating directly, Hacktoberfest is a way to encourage the global community to help make the world of open source software a better place. How does it work? To participate, sign up directly on the Hacktoberfest site. You can sign up anytime during the month of October. Projects on GitHub or GitLab can opt in to participate by adding the hacktoberfest topic to their project. You can often find issues that will have the hacktoberfest tag added to them. This means they're open to support on solving these issues, and that it will count towards your participation! There are only a few simple rules: - Pick an issue you'd like to work on from any participating project and write a solution. - The solution must contain text and code you wrote yourself - no copying, no bot scripts! - It's also important to make contributions that provide value to the project. Find ways you can contribute that actively help the project, its maintainers, and the people who use it. Documentation is a GREAT way to get involved. Or maybe there's an issue you've run across while using it that you found a solution to. The key is to add value- some fixed typos and small writing changes are great, but try to avoid simply formatting files or something like adding your name to a list. Quality over quantity! - Submit your solution as a pull request (PR) on the project's page. - Your pull request counts towards your participation when it's approved by maintainers, has been merged into the project, or is marked with the hacktoberfest-accepted label. - Do this 4 times in the month of October, and you're good! The first 50,000 people with 4 approved pull requests can either get a free t-shirt or have a tree planted in their name. Is This Dot Labs Participating? We are! This Dot has a number of repositories for resources we share with the community year-round. And this year, helping us keep these resources accurate and up to date counts towards your Hacktoberfest progress! Here's the list of repositories we have enabled for Hacktoberfest participation: - Podcasts - Newsletters - Community Slacks - Learning Resources - Bootcamps - Meetups - Conferences - Dev Tooling For all of these repositories, we're looking for YOUR help in growing our library of resources, ensuring the data we have is still accurate, and helping to make these resources easier to navigate. Have a resource you love that you don't see listed? Try to check a resource out and the link no longer works? Great at organizing, and want to create a table of contents? All of this help is greatly appreciated! Ok, but what IS a pull request? Great question! Let's create an actual pull request on one of these repositories, and see how it's done! What You'll Need to Get Started First, you'll need to have an account on GitHub. If you don't already have one, you can sign up here. You'll also probably want a code editor. There are a ton out there to choose from. However, GitHub has also added the amazing ability to run a web-based version of the popular editor VS Code, which is what we'll use! Step 1: Find an Issue to Work On For this walkthrough, we're going to add some excellent tech podcasts to the Podcasts repository! So we'll go visit that webpage and double check to make sure the podcasts we want to add don't already exist in the list. In our case, we're in luck, and we have a few to add that don't already exist in the project! Step 2: Make a Copy of the Repository to Work From To add your own work, you'll need to make a copy that's tied to your account. To do this, we'll make a fork of the repository. You'll find this button in the upper right hand corner of the page. Click that, and it will ask you where you want to make the fork. Pick the account you want to work from (often you'll only have one account, but some folks might have a separate work account as well). GitHub will do a little magic, and we'll now have our own version of the project! 🎉 > Some projects will also have a mention in the README file of their project pointing to contribution guidelines. Make sure you read this if you're wanting to work on this project! It will give you any specifics for running the project and submitting the pull request when you're ready. Step 3: Create a New Branch to Make Your Changes On It's almost always recommended to create a branch when you want to make changes on a project. This provides the maintainers with a way to view what's different between your changes and the current, up to date project, and ensures that anything that accidentally breaks the project isn't automatically pushed live when the changes are saved. So, let's use this web-based editor! Once GitHub has redirected you to your personal copy of the repository, simply hit the . on your keyboard, and watch the magic happen. 😎 It should load the editor directly in the browser window, and once it's done, you'll see something like this: And we're in! Now, we want to make a branch to work off of. We can do this in VS Code by clicking on the third icon down the left-hand list, the one with three small dots and lines connecting them. If you hover over it, it will say "Source Control". Then, from the menu in that panel, we'll create a new branch for our changes. You'll want to name your branch something that describes what you're working on. If the issue you've picked up has a number associated with it, be sure to include that too. The editor will open a box for you to put in the name you've picked, and will ask if you want to switch to that branch. Switch over, and we're ready to work! Step 4: Make the Changes! Now, let's add those changes! I'm going to add a few podcasts I enjoy in the categories they fit best with, and provide the links to them. Make sure you save the file as you go, so you don't lose your work! Any lines you've edited will be highlighted on the left hand side, so you can quickly view where your changes are. Step 5: Commit Your Changes Once you've made the changes you want to make, tested your code, spell-checked your text, and you're feeling good about your work, it's time to get those changes pushed onto your copy of the repository. There's a few steps here: - Add the changed files to our source control list - Make a commit - a description of the work we did, tied to a uniqiue identifier - Push the changes to our copy of the repository If you've noticed, the "Source Control" icon we clicked on earlier will now have a little circle with the number of files we've updated on it. Click into this menu again, and we can do all these steps from here! We'll see a list of the files with changes made. Next to each file, there will be some icons on the right side. For each one, we'll want to click the little + icon, to _stage_ those changes. If you have a lot of files to add, you can also click the + icon from the "Changes" section as well to add all of them at once. We'll now see that these files have moved from "Changes" to "Staged Changes". Great, now our changes are staged and we're ready to write our commit! In the text input at the top of the section, write your message - a short description of the work you did. Spaces are allowed here and there's not a hard length requirement, but try to keep it fairly short and succinct so others can quickly tell what changes we made. When you're satisfied with the message, press ctrl and enter together, and the editor will automatically _commit_ those changes to your branch! Step 6: How to Open a PR (Pull Request) The moment you've been waiting for: we're ready to make an official pull request to the main repository! Since we've been using GitHub's web editor, we'll create our pull request directly from the same editor! And I'll also show you what it would look like from the main repository view as well, if you work from a local editor instead. Both options will need the same information, but the visual is a little different. GitHub will be able to guess a majority of the information for you, but there's a few things to point out. - You'll be selecting your branch from your copy of the repository, and sending it to a branch in the remote / original repository. - Double check that it has selected the right branch from your copy of the repository. You should see the name of the repository with your user name before it, and the name of the branch you want to submit. - Also, make sure that the original repository you're sending it to is correct. It should show the company name, followed by the project name, and the branch you want to send this to. Often, it will be "main", but sometimes projects will want you to submit your request to a different branch. Make sure you check for a contribution guide if they have one! - Write a title for the request. This will be shorter than the commit message we made before, and describes the work we did overall. - Write a description. This will be a bit more in detail on the work we did. Some projects might have checklists of things they want to make sure you did, or they might want a list of the commits you created. There's no wrong way here - just make sure if the project specifiew what they want here, that you follow that! - When you're ready, click create! From the Web Editor: There's a button at the top of the "Source Control" menu that has a straight line next to a curved arrow with a plus sign (it's the second from the left side). Click this, and it will open the menu for you to fill out. From the Website: You'll often see a colored bar above the repository when you've got a branch that's able to be used for a pull request. Click the green button inside of it that says "Compare & Pull Request", which will take you to the form to fill out. Step 7: Adjust for Feedback & Wait for Approval! And that's it. Our pull request is created! The project maintainers can now view the changes you've made. You can see your pull request on the main repository's page, under the "Pull requests" tab. Often, there might be changes they'd like you to make, or questions they want to ask about the work you've done. Be polite and honest, work diligently to make the requested changes, and ask questions if you don't understand something! When you make the changes, you can add those changes directly to your branch on your copy of the repository, and the pull request will be automatically updated. Just leave them a comment on the pull request view so they know there's new changes to review! Once the maintainers are satisfied with your work, your pull request will be approved and merged into the project! Then you'll get to see the work you've done directly in the main repository and on the live site (if they have one). Excellent job! You're Ready to Help Open Source Projects! Now that you know how to create a copy of a repository, find issues to work on, complete that work, and submit the pull request for it, you're ready to complete your 4 pull requests and win a sweet t-shirt or have a tree planted! Here's our list of repositories that are accepting contributions for Hacktoberfest again: - Podcasts - Newsletters - Community Slacks - Learning Resources - Bootcamps - Meetups - Conferences - Dev Tooling > Feeling like you're "too new" to coding, and aren't sure what you can work on? Try filtering your searches in issues by labels like "good first issue" or "help wanted"! And also, helping with documentation is a fantastic way to start to get involved! It's often hard to keep up with documentation, but incredibly vital to helping new folks start using a tool. Figuring out how something works or updating the docs with current information is completely valid and worthwhile! The Hacktoberfest site also has some great resources for finding issues to work on for beginners and intermediate folks! We also have some great open source tooling that we're working on! We'd love to have you check these projects out and let us know what you think! We're always open to suggestions for how we can improve them and other tools you'd like to see: This Dot's Open Source Projects. Good luck on your contributions! We're so excited to see what you work on, and welcome your help in providing excellent resources for the community!...
Oct 19, 2021
12 mins