This Dot Blog
This Dot provides teams with technical leaders who bring deep knowledge of the web platform. We help teams set new standards, and deliver results predictably.
Remix Deployment with Architecture
Intro Today’s article, will give a brief overview of the Architect framework and how to deploy a Remix app. I’ll cover a few different topics, such as what Architect is, why it’s good to use, and the issues I ran into while using it. It is a straightforward process, and I recommend using it with the Grunge Stack offered by Remix. So let’s jump on in and start talking about Architect. Prerequisites There are a few prerequisites and also some basic understandings that are expected going into this. The first is to have a GitHub account, then an AWS account, and finally some basic understanding of how to deploy. I also recommend checking out the *Grunge Stack* here if you run into any issues when we progress further. What is Architect? First off, Architect is a simple framework for Functional Web Apps (FWAs) on AWS. Now you might be wondering, "why Architect?" It offers the best developer experience, works locally, has infrastructure as code, is secured to the least privilege by default, and is open-source. Architect prioritizes speed, smart configurable defaults, and flexible infrastructure. It also allows users to test things and debug locally. It defines a high-level manifest, and turns a complex cloud infrastructure into a build artifact. It complies the manifest into AWS CloudFormation and deploys it. Since it’s open-source, Architect prioritizes a regular release schedule, and backwards compatibility. Remix deployment Deploying Remix with Architect is rather straightforward, and I recommend using the Grunge Stack to do it. First, we’re going to head on over to the terminal and run *npx create-remix --template remix-run/grunge-stack*. That will get you a Remix template with almost everything you need. *Generating remix template* For the next couple of steps, you need to add your AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY to your repo’s secrets. You’ll need to create the secrets on your AWS account, and then add them to your repo. *AWS secrets* *GitHub secrets* The last steps before deploying include giving CloudFormation a SESSION_SECRET of its own for both staging and production environments. Then you need to add an ARC_APP_SECRET. *Adding env variables* ` With all of that out of the way, you need to run *npx arc deploy*, which will deploy your build to the staging environment. You could also do *npx arc deploy —-dry-run* beforehand to verify everything is fine. Issues I Had in My Own Project Now let's cover some issues I had, and my solution for my own project. So, I had a project far into development, and while looking at the Grunge Stack, I was scratching my head, trying to figure out what was necessary to bring over to my existing project. I had several instances of trial and error as I plugged in the Architect related items. For instance: the arc file, which has the app name, HTTP routes, static assets for S3 buckets, and the AWS configuration. I also had to change things like the *remix.config* file, adding a *server.ts* file, and adding Architect related dependencies in the package.json. During this process, I would get errors about missing files or missing certain function dirs(), and I dumped a good chunk of time into it. So while continuing to get those errors, I concluded that I would follow the Grunge Stack, and their instructions for a new project. Then I would merge my old project with the new project; and that resolved my issues. While not the best way, it did get me going, and did not waste any more time. That resolved my immediate issues of trying to get my Remix app deployed to AWS, but then I had to figure out what got pushed. That was easy, since it created a lambda, API gateway, and bucket based on the items in my arc file. Then I realized, while testing it out live, that my environmental variables hadn’t carried over, so I had to tweak those on AWS. My project also used a GitHub OAuth app. So that needed to be tweaked with the new URL. Then it was up and running. Conclusion Today’s article covered a brief overview of what Architect is, why it’s good to use, how to deploy a Remix app and the issues you might have. I hope it was useful and will give others a good starting point....
Aug 30, 2022
4 mins
Introducing Vue and Angular Versions of Framework.dev + New Landing Page
Our team created Framework.dev to help developers feel less overwhelmed when researching technical resources. We appreciate how important it can be to have a starting point when it comes to learning a new technology, or keeping up to date with the latest developments in the OSS community surrounding a stack. Previously, we started with just React, but our solution is deliberately extensible, and designed to be themed and filled in with different content for different frameworks. That's why we are happy to announce our new Vue and Angular versions for Framework.dev, a series of websites dedicated to cataloging resources to learn and develop in a given frontend framework. Our newest versions have the same features as the React version, which allows developers to search, compare, and discover libraries and resources! By adding tags and filters with a number of different attributes to all resources, and also making all the titles and descriptions searchable, we make the task of finding what you are looking for way easier. And who knows? Maybe in that search for finding out which library is the best for your needs, you ended up encountering one which you have never heard about before. Or perhaps you are just not sure which one to choose because all the options are solid. Well, we got you! With Framework.dev, you can compare libraries to look at metrics like the number of downloads, test coverage, and Github stars so you can get an idea of how popular and well-supported it is. To help you in these decisions, we've made it so you can take any set of libraries, and arrange them into a sortable table with a number of useful statistics sourced from npms. Our New Landing Page Since our plan is not to stop here, but to keep updating and making the site much bigger with more resources, frameworks and more, we decided that it was time to launch our landing page! This is where you can easily access the framework you are most interested in. Take a look at it! Help Build and Curate the Content! We are just getting started, and we know there's still a lot of content to add and cover! Framework.dev is hosted and maintained by This Dot Labs, but is a fully open-source project. No single person can keep up with how the frontend framework ecosystem constantly evolves and changes, but we might just stand a chance if we work together. Framework.dev is made for the community, and we hope community members will be inspired to enrich it. Do you have a favorite book that you think others should know about? Do you know about a cool feature that we could add? Did you encounter a bug? Then go look at our contribution guidelines and contribute to Framework.dev today!...
Jul 13, 2022
3 mins
How to Contribute to Redux with Mark Erikson
We are kicking off a brand new series of videos in 2022 to help developers learn how they can contribute code to some of the world’s most popular JavaScript frameworks and technologies. Subscribe to This Dot Media’s Youtube Channel. For those interested in React state management, I sat down with Mark Erikson, maintainer of Redux recently! If you would like to check out that interview, you can see it here. What is Redux? Redux is an open source JavaScript library that helps developers manage and centralize global state in their large-scale applications. By wrapping state in a store, you can alert all code that subscribes to the store of updates to the state. Mark Erikson Mark Erikson started contributing to Redux in 2016. After working with JavaScript and Backbone for years, Mark began learning React and Redux, which eventually led him to a chat channel called Reactiflux. While hanging out on these channels, he noticed a ton of people asking the same questions, which inspired him to volunteer to write an FAQ page for the Redux project. Shortly after, Redux co-creator Dan Abramov gave Mark commit rights to the repository, allowing him to triage issues and answer questions. This goes to show anyone can contribute to open source - you just need to get started! What to Know Before You Get Started Before jumping into contributing to Redux, it's important to know a few key things about the repository: - There are three primary repositories within the Redux org. These include redux-core, react-redux, and redux-toolkit. - Redux-toolkit is how the team wants people to use Redux today and where the bulk of the open source work is taking place. - Each repository is structured similarly, so once you understand one, it'll be easy to understand the other two! First Steps for Contributing Since most of the work is taking place in redux-toolkit, new developers will find that it is the most active. In fact, new contributors can learn more, and even help out by reading and responding to questions in the discussions tab located in redux-toolkit as a way to start contributing easily. Redux-toolkit also has many open issues that developers can work on or triage! Developers can help by reproducing bugs or by editing and adding to documentation. If you're interested in helping in redux-core, Mark is looking for TypeScript experts who are interested in reviewing types! If you are interested in contributing but need a little additional guidance, Mark invites you to reach out to him with your questions and he will do his best to get back to you! Good luck contributing, and we hope you have fun submitting your first PR to Redux!...
Mar 10, 2022
2 mins
Introducing Framework.dev
Have you ever started to learn a technology and felt overwhelmed by the amount of information out there and became paralyzed, not knowing where to start? We at ThisDot can certainly relate, which is why we are creating framework.dev...
Mar 3, 2022
3 mins
How to Contribute to Blitz.JS
This Dot Media is kicking off a brand new series of videos in 2022 to help developers learn how they can contribute code to some of the world’s most popular JavaScript frameworks and technologies. Subscribe to This Dot Media’s Youtube Channel. In the newest episode of this series, looking at the best practices for contributing to open-source web frameworks, I spoke with Brandon Bayer, Founder of Flightcontrol and Creator of Blitz.js. If you would like to check out that interview, you can see it here. What is Blitz.js? Blitz.js is a web framework built on Next.js that offers out-of-the-box features including a “Zero-API” data layer that eliminates the need for REST/GraphQL, and was modeled after Ruby on Rails. Brandon Bayer Brandon Bayer is the Founder of Flightcontrol, a full-stack deploy platform for Nest.js and Blitz.js. Additionally, he is the Creator of Blitz.js, and also offers independent software engineering consulting services. Brandon created Blitz.js after coming from the Ruby on Rails community, and wanting something similar with “batteries included” in the JavaScript ecosystem. What to Know Before You Get Started Developers who are interested in contributing to Blitz.js should visit the Blitz.js repository, read the documentation to learn how to contribute, and discover more about the community! *Quick Tips!* - Check out Blitz Project Dashboard on Github, and view the “ready to work on” column for issues that have been unassigned and need help! - Join the Discord and get involved in the community! The Best Way to Get Started Those who are just getting started with contributing to Blitz.js can help with code reviews, documentation, and addressing issues in the “ready to work on” column in the Blitz.js repository. If you are interested in working on a particular issue, you can comment on it, it will be assigned to you, and then you can start working on it. *Quick Tips!* - To find ideal issues for new contributors, look for the tags “good first issue” and “second first issue”. - If you are using Blitz and you find a bug, you are encouraged to bring that to the attention of maintainers. - If you are looking to build relationships and get involved on a regular basis, you can become a maintainer. There are different levels of maintainers like L1, L2, and Core Team. On the Blitzjs.com documentation page, there are descriptions on what it means to be what type of maintainer. How to Submit a PR Once you submit a PR, someone should review it within a few days, possibly request that you make changes, and then it may be merged. Sometimes PRs might be on hold until there is a release, but usually they are merged immediately. *Quick Tip!* The Blitz.js team doesn't have a lot of people reviewing PRs, so contributors are welcome to look at PRs and comment to make suggestions! What About Attending Core Team Meetings? Currently, the Core Team does not offer contributor meetings. However, earlier in the framework’s history, the Core Team hosted meetings that were recorded and shared on the Blitz.js Youtube channel if you would like to review old meetings. __Are There Ways to Contribute to the Ecosystem Without Coding? Those interested in contributing to the Blitz.js ecosystem without contributing code can: - Help triage issues when new issues come through - if there is a bug, see if you can reproduce it, or ask the original person for details. - Speaking at meetups and conferences. - Making courses and writing books. - Translating the docs into other written languages. - Contribute anything that can spread the word about Blitz.js! Blitz.js Success Stories Aleksandra, who is a TypeScript expert, started using and contributing to Blitz.js. Whenever there was a particularly challenging problem with Blitz in TypeScript, Brandon Bayer would go to her and ask for help. That led to her working full time for Blitz.js! Level 2 maintainers Simon and Juan have been successful too. Simon, who has only recently gotten started with the project, has been super helpful in building items like SuperJSON. Juan got started through translating docs, and he’s been working as a Maintainer ever since. Ready to Begin? You can find the Blitz.js Github repository here....
Feb 17, 2022
3 mins
How to Contribute to RxJS
This Dot Media is kicking off a brand new series of videos in 2022 to help developers learn how they can contribute code to some of the world’s most popular JavaScript frameworks and technologies. Subscribe to This Dot Media’s Youtube Channel. To continue our series, highlighting best practices for developers interested in contributing to their favorite technologies, I met up with my good friend and creator of RxJS, Ben Lesh. If you would like to check out that interview, you can see it here. What is RxJS? RxJS is a library for reactive programming that uses Observables to make it easier to compose asynchronous or callback-based code. It is a rewrite of Reactive-Extensions/RxJS with better performance, better modularity, better debuggable call stacks, all while staying mostly backwards compatible, with some breaking changes that reduce the API surface. Ben Lesh Ben Lesh is an international speaker and RxJS Core Team Member. His involvement with the framework started a few years ago, when he was asked to work on a rewrite due to his open-source experience in other projects at Netflix. What to Know Before You Get Started According to Ben, the codeofconduct.md and contributing.md documents are the best places for new developers to start. It is crucial that new contributors abide by community standards and the correct commit format, so be sure to read through! *Quick Tips!* -Everything in RxJS is written under src/internal, where you can look at all the internals of RxJS. -The commit message generates the changelog, which can be found on changelog.md. The Best Way to Get Started When I asked Ben what areas of the repository were best for new contributors, and what areas needed the most attention, he of course said: documentation. But it’s true! According to Ben, devs can simply click the “Improve Documentation” button, and do a direct commit. Presently, the team could significantly benefit from contributors interested in checking links to ensure that they are not broken, revising grammatical errors, ensuring all information is up to date, and adding edit buttons in the documentation for individual pages. However, if developers are looking for a different challenge, they can see open requests for contribution by checking out the “help wanted” tag in the issues section. *Quick Tips!* -Don’t simply submit a bunch of PRs to get on the contributors list! Focus on contributing helpful, meaningful work that will advance RxJS! -Because issues are not checked every day, you want to make sure that there is not already a PR for it, and that it hasn’t already been assigned to someone. Also, make sure to look through the PRs to ensure that the issue is not being addressed in both open and closed PRs. What About Attending Core Team Meetings? Core Team meetings typically address in-depth issues and questions related to RxJS, and are not open to the public. However, contributors can receive invitations based on their PRs and need, so if developers are interested in attending Core Team meetings, the best thing to do is create a presence in the RxJS Community! Though meetings aren’t open or recorded, community members can view the issues, and see the tag “agenda item” to see what topics will be addressed at upcoming meetings. Usually, the discussions are commented on in the issues. *Quick Tips!* -If you are interested in getting involved, but don’t want to contribute code, go out into the world and review external articles or Stack Overflow, and help in the community! -Blog posts and explanations about RxJS are also valued by the community and Core Team! Ready to Begin? You can find the RxJS repository here!...
Feb 10, 2022
3 mins
How to Contribute to Redwood.JS
This Dot Media is kicking off a brand new series of videos in 2022 to help developers learn how they can contribute code to some of the world’s most popular JavaScript frameworks and technologies. Subscribe to This Dot Media’s Youtube Channel. In our first episode, I sat down with David Price one of the creators and maintainers of RedwoodJS! If you would like to watch this interview, you can find it here! What is RedwoodJS? RedwoodJS is an app framework built on React, Prisma, and GraphQL that is especially useful for startups interested in prototyping since it integrates everything someone would need to carry out fullstack development out of the box. These integrations include Storybook, Webpack/Babel, and more with zero configurations. The goal of RedwoodJS is, in part, to allow developers to focus on what makes their applications unique and interesting by handling a lot of the configuration logic inherent to deploying fullstack applications. David Price David Price is the Founder of human(Ethos), a San Francisco-based consulting firm that helps product teams build cultures of performance, and currently works as a Developer in Residence at Preston-Warner Ventures. Beyond this, David is one of the Creators of Redwood.JS, and serves as a Maintainer. Important Resources to Check Out Before Contributing If you would like to learn more about the specific features offered by RedwoodJS, you can read up on the official documentation here. You can check out the RedwoodJS repository here. David suggests that new users spend time in the packages folder since these are all the packages that will get published to npm. And finally, if you would like to become engaged with other developers interested in RedwoodJS, you can join the official community server and/or the official discord server. The Best Way to Get Started Before contributing any code to RedwoodJS’ open-source repository, David Price suggests introducing yourself to and getting support from the larger RedwoodJS community using some of the resources above: *“The way to get started is to get the moral support in the community, and say you are interested in helping out! And they can direct you!”* Not only will that give new contributors an idea of what current projects are in the works and where they can help, but it can help them connect with other developers who will direct them to the most ability-appropriate tasks. *PRO-TIP from David: There is a file in the repo itself, called contributing.md, that shows you how to get started on actual contributions!* New contributors can also click on the “help wanted” tab in Github issues to see what work is needed, and available! There are also tags called “good first issue”, which are great entry points to the project. Another tag is “bug/confirmed”, which allows contributors to help with bugs! Great at reviewing code? Code reviews support functional testing in the PRs! Inside of the CI checks, there is a link to Gitpod which will pull up a VScode virtual editor that creates a test project. You can use this to help run tests! Anyone can come into a PR, run a test, and go through the process to report back what worked and didn't work. Attending RedwoodJS Contributor Meetups Visit the community forums for RedwoodJS to learn more about how the community is structured. As mentioned above, there are a number of useful discussion boards where you can find information about announcements, docs, and opportunities to contribute. Once you are active on the forums, you will be eligible to receive invitations to private contributor meetups, but be sure to ask for one, since there may not be Core Contributors who are actively searching for folks to invite! Contributor Success Stories - Peter Colapietro started opening and contributing to PRs for Hacktoberfest. Because of his consistent, high quality work since October, he now helps with the Storybook team, working on a really important PR! - There are collaborators working with diversity outreach for Redwood.JS, and they have been brainstorming a lot of ideas on how to get people involved! Multiple contributors have landed jobs after working with RedwoodJS. The community has been growing and evolving. Jobs are being created within the community....
Feb 1, 2022
3 mins
How to Contribute to Angular
This Dot Media is kicking off a brand new series of videos in 2022 to help developers learn how they can contribute code to some of the world’s most popular JavaScript frameworks and technologies. Subscribe to This Dot Media’s Youtube Channel. To continue our series in which I interview prominent open-source maintainers to find out some best practices for contributing, I spoke with Mark Thompson, Developer Relations Engineer at Google and Angular Core Team member. If you would like to check out that interview, you can see it here. What is Angular? Angular is a Typescript-based open source framework created and maintained by Google and used for building web and mobile applications. Mark Thompson Mark Thompson is a Developer Relations Engineer who began working for the Angular Core Team as a component of his employment at Google. What to Know Before You Get Started If developers are interested in contributing to Angular, they will want to start out by visiting the official Angular repository. Once there, they can find the contributing.md file to get an idea of the guidelines for contributing. After that, contributors will be able to explore the various projects within Angular such as Components, CLI, and more. *Quick Tips!* - Spend time going through the contribution guide, and learn the rules so the Core Team can best help you! There are a lot of automated processes involved! - Sign the CLA before sending any pull request! This is required before the Core Team can accept your PRs! The Best Way to Get Started The easiest place for new contributors to start is in the documentation! Working on the documentation gives you a place to use your existing knowledge, or even your proofreading skills! Anytime you see an issue in the documentation, you can submit an issue and follow it up with a PR! *Quick Tips! - Don’t come in too hot! Don’t use issues as opportunities to attack other developers. No Core Team member or contributor creates anything with the intention of causing intentional harm. - Don’t spam the comments. The Core Team keeps up with comments to the best of their ability and will eventually get to yours. - Go through the feature requests and ‘thumbs up’ the ones that you like so we can make sure they are prioritized! What About Attending Core Team Meetings? Currently, there are no open meetings for Angular, and prioritization meetings are limited to Google employees on the Angular Team and those who receive special invitations. However, anyone can look at the roadmap to find out what the team and other contributors are working on. *Quick Tips!* -Consider hosting your own meetup, event, or creating content for the Angular community. Angular Success Stories Before Minko Gechev became a Googler, he was contributing to Angular. His passion for Angular led to his career at Angular, and he is now the team lead for developer relations. Will your story be next? Ready to Begin? You can find the Angular Github repository here....
Jan 27, 2022
3 mins
Announcing Angular GitHub Clone for starter.dev showcases
The Engineering team at This Dot Labs loves building open-source software, providing resources to the community, and collaborating with our clients and partners. In cooperation with the Angular team, we have developed an implementation of GitHub’s user interface to deliver a project to the community that demonstrates the power of Angular while providing a fully featured open-source application for developers to use as a learning tool. We’re including this Angular GitHub Clone as part of a new initiative we’re working on called “starter.dev GitHub showcases”, and we are excited about its future. If you want to jump into the code, visit the GitHub repository, or you can check out the deployed application at https://angular-apollo-tailwind.starter.dev/. --- Our Goals Based on the initial projects by Trung Vo (Spotify clone / JIRA clone), we were looking to create an example project that goes beyond the basics of a TodoMVC application and really showcases the power of the technology. Specifically, we wanted to showcase Angular with routing, forms, and global state management. What we built For this project, we utilized Angular v13 with Apollo Client and Tailwind CSS to bring a GitHub user interface to life that features: User login via GitHub OAuth User Dashboard featuring a user’s top repositories and gists for quick access Repositories including file tree exploration, file viewing, issue lists with filtering, and pull requests with filtering User Profiles with near feature parity with the GitHub UI We also created a Serverless Framework based server to manage the OAuth handshake between the application and GitHub servers for security purposes. Why Apollo Client? At This Dot Labs, we love GraphQL, and GitHub has an amazing Public GraphQL API for consumption that we were able to leverage to build all the features in this application. Angular Apollo Client provides us with a GraphQL client and global state management out of the box. Check out our Issues Store to see how we were able to leverage Apollo Client to fetch data from Github and inject it into a ComponentStore for consumption. Why TailwindCSS? Other projects we’ve seen demonstrate how to extend existing component libraries, and we didn’t want to replicate this behavior. Instead, we thought it would be great to demonstrate how to use a CSS utility framework in conjunction with Angular component stylesheets. This afforded us an opportunity to show the Angular community the power of a new tool and further community excitement around a framework agnostic technology that has reshaped the CSS space. Why Serverless Framework? We wanted an easy to use backend ecosystem for any developers wanting to fork and test this application. Additionally, for those looking to deploy this backend, we wanted to find an economical solution. With the serverless-offline plugin, we were able to provide a local first development environment to developers while giving them the ability to ship the API to their favorite cloud hosting provider that supports serverless functions. How to use starter.dev showcases We recommend starting with an exploration of the codebase. To get started, follow these steps: ` In both .env files, you’ll see missing values for GITHUB_CLIENT_ID and GITHUB_CLIENT_SECRET. To generate these values, please follow GitHub’s Creating an OAuth App instructions to generate your personal client and secret that you can then input into your .env files. Now, you can run yarn start in both directories and point your browser to localhost:4200 to see the app running. From here, you can start exploring and experimenting with project components. What should I do next? The project README includes several ideas and features that we’ve vetted for feasibility. We’ve given some high level details about the feature and included how difficult we believe it will be to accomplish. We think these are great features to both improve the app and provide you with an opportunity to experience Angular without having to start your own project or find projects that need contributions. New to Angular and want feedback on your approach? Send us a pull request with your changes, and we’d be happy to review it and provide feedback. If it’s the first submission for a particular feature, we’d love to include your change and attribute it back to you. --- We plan on extending starter.dev showcases to include more Angular stacks and examples to give the community even more resources. If you’re interested in contributing to starter.dev showcases or have ideas for new features or showcases, we’d love to hear from you. Our GitHub issues are open for collaboration and pull requests are always welcome, but not required....
Jan 25, 2022
4 mins
How to Contribute to Node.JS
This Dot Media is kicking off a brand new series of videos in 2022 to help developers learn how they can contribute code to some of the world’s most popular JavaScript frameworks and technologies. Subscribe to This Dot Media’s Youtube Channel. To kick off our series, highlighting best practices for developers interested in contributing to their favorite technologies, I spoke with Michael Dawson, the Node.js lead for Red Hat and IBM, as well as a collaborator and technical steering committee member for Node.js. If you would like to check out that interview, you can see it here. What is Node.JS? Node.js is an open source, back-end Javascript server environment released in May 2009. Presently, it runs on the V8 engine, and executes JavaScript outside of the browser. Node.js is free to use, and compatible with a variety of platforms, including Windows, Linux, Unix, Mac OS X, and more. Michael Dawson Michael Dawson began working on Node.js six years ago, while building the Java runtime as a part of the IBM Java team. Around this time, Node.js was quickly gaining popularity, and IBM wanted to be able to support its growth as an up and coming runtime. Michael helped contribute to the upstream to V8 as part of the team at IBM, and since then, he has worked closely with Node.js as part of the Technical Steering Committee. What to Know Before You Get Started Folks interested in contributing to Node.js should start by checking out the official Node.js repository. There, interested developers can find a number of helpful resources, including the public Node calendar, and conversations where developers can learn more about what teams are aggregating, and what active contributors are working on. *Quick Tips!* - The Node team is committed to fostering an open and welcoming environment where everyone feels able to participate. While engaging with others, be professional and civil. - If you choose to start contributing, be proactive and help make contributions instead of just opening issues and making suggestions. The Best Way to Get Started According to Michael Dawson, each repository has issues related to specific repositories, so developers can find the kinds of repos that they’re interested in contributing to, and pinpoint corresponding issues that they can help address. If you are looking for a great way to start, you can check out the ‘good first issue’ or ‘flaky-test’ tags! These are issues that fail occasionally, and cause the project a lot of grief. However, they are also some of the more accessible issues that new contributors can approach, so it’s a win-win for everyone involved. *What does the Node.js team need help with the most?* - Getting up to speed on subsystems. There are not enough people involved in consistently reviewing different sections like http. - Build and release has remained a huge undertaking, but it is a long path to ramp up. This is great for people with interest in infrastructure. - The Next-10 project is a great place to contribute in order to shape the future of Node.js. The contributions of folks who are external to Node, or who have expertise that could bring a new fresh set of eyes, are encouraged to help. *Are there non-code contributions that can help the Node.js ecosystem?* - People interested in contributing, but not interested in contributing code, can help edit and maintain documentation, and can contribute to discussions on Node.js community forums. - Those who are proficient in multiple languages and comfortable with translation are highly sought after, and their contributions are greatly appreciated! - Those with design skills, interested in website redesign will also find a home in the Node.js community. What About Attending Core Team Meetings? Presently, Core Team meetings are only open to Core Team members. However, unlike many frameworks, the team behind Node.js records all meetings and makes them publicly available for viewing on Youtube. In addition, meeting notes and links to the meetings are generated as issues in the corresponding repo. If developers are interested in attending meetings around Node.js, they can attend open meetings that correspond to specific groups in the Node.js community. Nearly every group has a public meeting. Ready to Begin? You can find the Node.js Github repository here....
Jan 19, 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