The latest articles on DEV Community by Luiz Gois (@developerluizgois). https://dev.to/developerluizgois https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F766219%2F77514905-b1ec-4c6e-93d1-710b326061f7.jpg https://dev.to/developerluizgois en Luiz Gois Mon, 08 Apr 2024 01:30:16 +0000 https://dev.to/developerluizgois/semantic-versioning-101-231-what-is-this-4adk https://dev.to/developerluizgois/semantic-versioning-101-231-what-is-this-4adk <p>When developing a project, part of your work as a developer will be to document and version your code. Have you ever noticed those numbers like 2.3.1 or 1.0.4? They aren't randomly defined! They're defined by a convention called Semantic Versioning.</p> <p><strong>What is Semantic Versioning?</strong></p> <p>You're developing or already have a super useful JavaScript package that other developers are using in their projects. Every new feature you implement in your package or every bug you fix needs to be communicated to the people using your package.</p> <p><strong>How should I do it?</strong></p> <p>This is where Semantic Versioning helps you! It breaks down the version number of your package into three parts: X.Y.Z.</p> <p><strong>X</strong> is the major version. This changes when you make changes that can break the code of people using your package.</p> <p><strong>Y</strong> is the minor version. This changes when you add a new feature but don't break people's code.</p> <p><strong>Z</strong> is the patch version. This changes when you fix a bug but don't change anything that people are already using.</p> <p><strong>Let's make it even easier for you to understand with these examples:</strong></p> <ul> <li>Do you release the first version of your package? 1.0.0.</li> <li>Added a new feature? 1.1.0.</li> <li>Fixed a bug? 1.1.1.</li> <li>Made big changes that could break people's code? 2.0.0.</li> <li>Fixed a bug in the new version? 2.0.1.</li> </ul> <p>This way, everyone can clearly understand the impact of changes in your package or project. Remember to also explain in your README what's new in your changes.</p> developer programming tutorial webdev Luiz Gois Tue, 02 Apr 2024 06:28:56 +0000 https://dev.to/developerluizgois/escolha-a-ferramenta-que-resolve-seu-problema-57a0 https://dev.to/developerluizgois/escolha-a-ferramenta-que-resolve-seu-problema-57a0 <p>You decide to dive into the world of programming and your first challenge seems to be choosing the language you will adopt. Well, actually, your concern should be something else: "What do I want to solve?"</p> <p>It's like choosing a tool to fix a broken object at home. You don't sit in front of the toolbox thinking, "What's the latest? What's the most popular?" No, you simply get the right tool for the job.</p> <p>It may seem a bit cliché to think that instead of trying to know a little bit of everything, the ideal is to delve deeper into the fundamentals of a language. But the reality is that, in fact, your best tool will always be the ability to analyze problems, design solutions and implement them effectively, regardless of language.</p> <p>From building small modules or packages to building your first complex and fully functional application, your goal should be a solid understanding of concepts that govern any language, such as: Algorithms and data structures, control structures and object orientation .</p> <p>Don't skip steps in your studies, don't hide your mistakes from yourself, start with what you know and make your development process public. Part of the process is understanding that you will find that you can easily adapt to different languages and environments.</p>