DEV Community: Basement Developers

Database for newbies: Hands On

Fernanda Fernandes — Tue, 26 Mar 2024 18:00:00 +0000

Knowing how to deal with databases are really important for every developer, so I will guide you through a tutorial on how to create one using MySQL on the terminal.

If you are a little bit lost when it comes to databases, I highly recommend you my first article of this series, where I explain the theory about databases. For now, lets get to the pratical part!

Hands on!
Preparing the environent
Creating our first database
- Datatypes and properties
CRUD
- Create
- Read
- Update
- Delete

Hands on!

There are many ways of creating a database, but I usually do it using MySQL on the terminal and DBeaver to visualize them when I need it. I decided to approach only MySQL on the terminal, specially because it is pretty simple to learn and very important to know the basics. Maybe one day I can show how DBeaver works. For now, I will show you how to deal with database through terminal, but remember - there are different ways of doing it.

Preparing the environment

First of all, you will have to install MySQL. I recommend you to install the MySQL Installer, which will have a lot of softwares to be downloaded, such as MySQL Workbench, MySQL Shell and many others. You should be able to download it on this link MySQL Installer and run the program. Then you should install MySQL Server, MySQL Workbench and MySQL Shell.

If you use other operational system than windows, or is having some issues you can ask me or try to take a look on some videos or articles more focused on the step-to-step installation.

After doing it, you will have to define the windows variable system. You should go on System's propriety>Advanced and then Environment variables

Find the system variable called "Path" and double click it. Then you should click on "New" and copy the MySQL server's path on it.

To test if it is working, open the terminal ( command prompt ) and typemysql. If an error saying that you have no access shows up, try te command mysql -h localhost -u root -p. It will ask the password and it will connect on MySQL.

Creating our first database

Now that we had set up our environment, we can work on the database! First of all, since we are going to do it using the terminal, you will have to open it and then connect on MySQL, which can be done with mysql command or mysql -h localhost -u root -p. You should be able to see something similar to the picture below.

Important: every MySQL command must finish with ";", and it is a good practice to write it on capital letters.

After that, it is important to acknowledge some important database commands, such as:

CREATE DATABASE <database-name>; : creates the database with the name specified on "database-name";
SHOW DATABASES; : shows the databases created;
DROP DATABASE <database-name> : delete the database informed and its values;
USE <database-name>: to select the database and be able to work on it.

Now the idea is to create a database named "store" and then a table named "products", which will have the fields id (the primary key), name, price and quantity.

To create this database we will use the command on the terminal:

CREATE DATABASE store;

After creating it, we will create the table named "products". We must select and enter the database first and then create the table with its fields, which will be id, name, price and quantity.

USE store; //Selecting the database
CREATE TABLE products
    ( id int auto_increment primary key,
      name varchar(40) NOT NULL, 
      price double(10,2) NOT NULL,
      quantity int NOT NULL
    );

Ok, now we have our database and our first table created! To visualize it we can use SHOW DATABASES; or SHOW TABLES; to see the tables created. We can also use DESCRIBE products; if we want to see the table's description.

Datatypes and Properties

Every time we create a table, we have to define the type of our data and some properties like if it is a primary key, a foreign key, if the data can be null, if it is unique... There are many properties and datatypes so We can use what will fit us the best.

One of the most common datatypes are:

Int : used for integer numbers, allows 4 bytes
Double: float number with double precision
Decimal(p,s) : used to store decimal numbers. "p" defines how many numbers will be allowed on the left side of the comma. "s" defines how many will be allowed on the right side of the comma.
Date : stores a date, which can be from 01/01/0001 to 12/31/9999.
Timestamp : stores an unique number that will be updated every time a table line is updated or created.
Varchar(n) : stores characters. "n" shows that we can define the amount of characters we are expecting to receive.

The properties are really important for our database, it will gives us more details. One of the most common ones are:

Not null : when applied to the data, means it can not be null, so it has to be given an value.
Auto_increment: mostly applied to primary keys, allows automatic generation of unique numerical values for a columns. Very used to create unique indentifiers.
Primary key: property used to define the data as primary key of the table
Foreign key : property used to define the data as foreign key of the table, creating a relationship between tables.

CRUD

After learning all of this about database, we can finally get to create a CRUD on the database. CRUD means create, read, update and delete, and it is really important for every developer, especially the back-end ones, to know how to do it.

In real life, CRUD is made using a programming language to get the data sent and store on the database. However, you need to know the SQL commands used to manipulate a database because even though you are going to use PHP, Java, Node or Python to do it, you probably will have to use the same SQL commands. After this article I will write another one creating a PHP application to show you how it works!

I highly recommend that you do these steps on your terminal to see how MySQL works! And, of course, feel free to try new things.

Create

To create or insert a data on our table we use the command INSERT INTO.

INSERT INTO products VALUES (null, 'Rice', 5, 10); //One way of doing it 
INSERT INTO products (name, price, quantity) VALUES ('Rice', 5, 10); //Another way of inserting data

In the first option is important to understand that the values informed must be at the same sequence of the table (id, name, price and quantity). The id can be null because it is an auto_increment data. And in the second option we inform which datas will be given. Also every time we insert a string, we have to use quotes.

Read

To read information of a table we use the command SELECT . There is some ways of selecting information.

SELECT * FROM products; //Example 1
SELECT * FROM products WHERE id = 1; //Example 2  
SELECT (name) FROM products WHERE quantity<5; //Example 3

We use ' * ' to say that we want to read all the fields - or columns - of the table, just like example 1. If we do not want it, we can inform which ones we want, like example 3.
We use the clause " WHERE " to filter the information we want to return. For example if we wanted to know which product holds the id equals to number 1, we would use the example 2. It is also possible to use the 'where' to return the products that has less than 5 quantities, just as in example 3. Except for specific situations, we shouldn't do queries without "WHERE".

Update

Is pretty usual to update the data registered, and we use the command UPDATE to do it. We can change the price of a product, for example, and we will use the "WHERE" in here too.

UPDATE products SET price=8, quantity=3 WHERE id=1;

In this example we are updating the product's price and quantity. Note that the WHERE is really important to define which register will be updated.

Delete

The delete operation, as you imagine, delete some register. The WHERE is really important in this type of query since if you do not use it, you will delete all the data from the table. So remember: Always use WHERE!

DELETE FROM products WHERE id=2;

And that's it!

I hope you've learned how to create a database and how to do CRUD operations on it! Remember that there are different ways of doing it, so feel free to research more about it.

If you have any questions you can send me a message! This content was created with my notes during the 100 days of code, in which I learned about database, PHP and Laravel.

And thanks to the people that reviewed my article and helped me to get here:

Database for newbies: Theorethical Approach

Fernanda Fernandes — Wed, 20 Mar 2024 19:28:31 +0000

Either if you have just started learning programming or if you already have some experience with it, I'm pretty sure you already asked yourself (or others) what a database really is, how you can deal with it, what is the difference between relational and non relational databases and what they are used for.

When it comes to programming, feels like our doubts are endless and sometimes we can feel lost in this sea of information. I will talk about some concepts that every beginner should know to create its first database. I hope to teach you at least something about database, one of the most important parts of the softwares.

What is database?
Types of database
- Relational
- Non-Relational
What is SQL?

What is database?

Before everything, it's important to understand what is data. Well, it is a value, like 21. But this data won't have a meaning unless we organize it, creating an information. For example, this number, all alone, could be an age, could be the total people that logged on your website or even your state number. Now if I say to you that we have the data: age = 21 , we can pretty much understand that the value 21 is someone's age. That's what we call information.

Knowing that, I can tell you that database is a collection of organized information. I like to imagine that databases are similar the process of moving to a new home. For example, when we are moving, it is normal to pack our things inside boxes. We would have a box for books, one for clothes and another for electronics. And in the end, we put everything inside a truck and take it to our new home.

In this example, our database would be the truck, because we have many boxes of specific things - a collection of organized information. This information is structured and normally stored in a computer system. (We use databases to store data, access and maintain it. )

To control a database, we are going to use what we call as Database Management System (DBMS), softwares used to visualize the database's tables, its information, and where we can also run queries (commands to do actions on the database) and many other things. It's basically a interface between the user - the person using the database - and the database itself.

We can say that every time we create, delete, update and read - and so much more - we will deal with a DBMS.

Examples of Database Management System:

MySQL
SQL Server
Oracle Database

There are so many options and we should choose the one that fit us and the project better.

Types of database

The most important types of database, the ones every beginner should know are:

Relational Database
Non-relational Database

Relational

This type of database is structured using tables with columns and rows, like the image below, and we use SQL to deal with this structure.
In a table, we will have:

Columns, which defines what every piece of data is (ID, Name, Age...) and its type;
Row, which holds the data given.

Every row in the table is a record with an exclusive ID, which we call as a key. In this table, for example, the key would be the numbers 1, 2, 3... We can see that every record has its own key, used to identify itself.

We have at least three types of keys that every beginner should acknowledge:

Key : it is basically one or more columns in a table that will be responsible for identifying in an exclusive way the rows.
Primary Key : this type will ensure uniqueness to the register, will refer the register on a relationship between tables and it is indexed, which increases the efficiency of our DBMS.
Foreign Key : it is a column that will kind of connect the tables using the primary key of each of them. We use this type of key to create relationships between tables. It is important to understand that the table that has the foreign key is called reference table and the one that is being referred is called referenced table or father table.

Non relational

Non relational database, also called as NoSQL (Not Only SQL, nowadays), are a type of database that don't use the table, and its columns and rows, as an organization scheme. It offers more flexibility because you won't have to worry about creating a table as we have to do on relational databases.

The storage on NoSQL is optimized and it adapts itself to fit every need. For example, it is possible to storage data as key/value, as JSON documents or as graphics.

NoSQL databases were created to solve the problem people were suffering until the late 90's, which was the difficulty to design databases that could cope with the scale and agility needed using the relational database, that wasn't able to do it at that time.

One of the most important features of NoSQL is:

Higher scalability
No complex relationship
Reduced costs

Non relational databases also have types, and two of them are:

Key Value: the most common one. Every item on the database will be stored as an attribute name (or 'key') with its value. For example: {"name": "Maria"}. The key is "name" and the value is "Maria". The most used databases in these cases are Redis, DynamoDB and Berkeley DB.
Document: stores each key with its document, and its principal feature is having all the information inside one document. This document normally is a JSON but it can also be a XML, for example. The most famous document database is MongoDB

There are a lot more information about this type of databases but this is the basics you have to know to start! Besides that, don't let this beginning stop you from digging deeper to learn more.

What is SQL?

SQL stands for Structured Query Language, a programming language used to work with databases created on the labs of IBM around the 70's. After a while, it became a pattern when it comes to data management.

We use this programming language to run queries on the database and we can retrieve, create or delete information from the database using the most various parameters. We just have to follow the syntax, just like any other programming language.

SQL has many commands but the most important ones are:

SELECT: search rows on the database table.
INSERT: insert new rows on the table.
UPDATE: used to update the data that already exists on the table.
DELETE: delete a register.

It is important to say that we use this commands with other parameters so we can make the queries very specific. And it is a convention to use SQL on Capslock.

SQL also has some conditions that we can add on our query in order to modify the registers that will be returned, like:

FROM: used to say what table will be consulted.
ORDER BY: used to organize the data returned in a specific order.
WHERE: used to specify the conditions of the data to be return. For example, if we want to see the users we have on our table that are older than 18 years old, we would use the 'where'.

There are many other commands in SQL but this is the very basic we need to know to create our first table and learn the commands to create our first CRUD, which stands for Create, Read, Update and Delete.

And that's it!

Through this article we learned the basics of database, like what it is, it's types and what is SQL. Now, we must learn how to create one, topic covered on the next article of this series.

This content was created based on my notes during the 100 days of code, in which I learned about database, PHP and Laravel, so I am really proud of it, since I knew almost nothing about it before starting the challenge. Also, feel free to ask me questions if needed!

And thanks to the people that reviewed my article and helped me to get here:

Protocols and how they work

Nicolas Evangelista — Tue, 05 Mar 2024 14:15:14 +0000

Disclaimer: This is an introductory article made by someone who's studying this subject, if you have some advice about the topics that are covered in here, DM me! We can have a chat and i'll be pleased to change this article. Thanks for reading!

After my last article about deploys and how they work (only an introduction about that topic), i started to study more about network and how we can connect our devices with another devices, and exchange data between them, of course.

I intend to do a series (don't know how many articles it will be) of articles about protocols and how they work individually, by the end of the series you might have a good understanding about how the internet works with all of these protocols working together, making a deploy look like child's play.

For this matter i'll be using the two most used models, the TCP/IP and OSI model, as both of them can be used as reference models, it'll help us understand the data flow within any type of network.

I've already knew OSI model from previous studies but it wasn't something that caught my attention, even TCP/IP, which is the backbone of our network communication didn't grab my attention, until now. Thus, i have decided to make some articles about some protocols that we already know, but showing - or trying to - how things work within the OSI and TCP/IP model.

OSI and TCP/IP stack

Both models are structured with layers, the OSI has 7 layers that correlates with the 4 layers of TCP/IP model, because both of them can be used as reference models.

First, let's go through what protocols actually do and why we call them a stack.

Protocols are basically an agreement between two or more hosts to establish some standards for this communication to happen, the stack is created so we can have a reference for the multiple stages in this conversation, and troubleshoot any issues that might show up. We can say that a protocol stack is the one that contains all the protocols, or services, that are needed for hosts to communicate with each other.

Furthermore the stack also represents the isolation between layers, so each layer will communicate with the same layer in the other host and will pass through the same stages using the same protocols, the isolation between layers is used so that the upper layers don´t have to occupy themselves with some services that are being executed on the lower layers.

Ok, but what these layers actually do?

The 1st layer of the stack is the physical layer and at this point i think that everyone knows how data is physically transmitted, doesn't matter what is the medium used, the computer will always see bits flowing.

The 2nd layer is responsible for transforming the transmission received, break into smaller pieces making data frames (hundreds or thousands of bytes) and transmitting the frames sequentially, the receiver can send back an acknowledgement frame to confirm that he has received the data frame correctly.

3rd layer might be the most famous one, it is the layer responsible for routing data through networks, besides that, it is responsible for dealing with congestion and the quality of the service offered by other layers, the network layer must assure that the correct protocols are being used. The data in this layer is called packets.

4th layers is the most challenging for me, specially because it's here where the magic - or the isolation - happens, this layer is responsible for isolating the communication process between the upper and lower layers, therefore it needs to put everything in order, so it must reorder every data received and handle the communication with care. This is a layer that must establish a connection that aims directly to the other machine, so it is a "direct" connection between two hosts, because the lower layers will handle the communication between the host and the next immediate host, so it could be a router, a switch or an access point, but the 4th layer will handle the communication between the host and the final destination.

The last 3 layers represents just 1 layer of the TCP/IP stack, and why is that? Well, that's an interesting topic, but we'll not deal with that right now, so let's keep moving.

The session layer is mainly responsible for taking care of the session tokens, like keeping track of whose turn it is to transmit data, will also manage this tokens so the two parties won't even attempt to send data without the token, and last but not least, making sure that the data that has been transmitted is in order even if a crash occurs during the data transmission.

Almost reaching the peak of the model we have the presentation layer, this layer we can look at him more like a support role, because it will help the application layer to communicate with some services offered by the session layer, it is through this layer that the session layer knows which services it needs to provide to keep the data flowing.

Last, but definitely not least, we have the application layer that have the duty of provide access to other services within the OSI model, it does that by using an interface that allows the end user to communicate with other services, all of the data generated with this input will be used by some other tools that will establish a connection with the layer below, then follow the process until it reach the other host.

To be continued...

This may sound confusing right now, but i'm sure that will help a lot with the understanding of the protocols that will be presented to you throughout your career as IT professional, because this layers can be seen by every communication process in a network, as i said at the beginning of this article, these are reference models, so it won't show you the answers about how an specific protocol work, but will definitely show you which rules the protocol has to follow to be part of some layer, or what functionalities some protocol have just for being part of any of these layers.

The next article will treat the communication process within a LAN, which is a local area network, how the data flow works and the responsibilities for every component, it'll give a better understanding about how reference models can be applied to real scenarios.

References

Tanenbaum, Andrew S. Computer Networks. 5th ed. Upper Saddle River, NJ: Prentice Hall, 2010.

Piscitello, David M., and Chapin, A. Lyman. Open Systems Networking: TCP/IP and OSI. Upper Saddle River, NJ: Addison-Wesley, 1993.

What we've achieved with 1 Month of Basement Devs

Daniel Reis — Mon, 19 Feb 2024 15:29:22 +0000

Running a community is a tough job, but after a few years of doing it, it becomes an easy task. This is the first month of our community and I want to show you what we have accomplished so far.

If you're planning to run a community or even join one, this series will show you how to measure the health of the community using Basement Developers as an example.

1. General Achievements
2. Demographics
- 2.1 New Members
- 2.2 Members Activation
- 2.3 Member Visits & Comunicators
3. Events
4. Partnerships
5. Published Content
6. What now?

1. General Achievements

First of all, I'd like to thank a few readers who joined the community. Now we have a couple of Polish people who engage there on a daily basis.

FYI: the community is looking for members like you, so join us ASAP! :D

Peak of 71 members in our latest weekly meeting.

Since we started the community, our weekly meetings have been the place to discuss new opportunities, projects, and other opportunities down there, and to listen to what the members have to say.

Your browser does not support the video tag.

Speaking of community feedback, most of our members are Brazilians who want to get used to English, so the first project made in the community was an overlay to translate everything we say in our weekly meetings from English to Brazilian-Portuguese! Cheers to Pantotone, the creator of this amazing tool!

Also, since we're starting to create projects, a new GitHub organization has been created to host all projects related to our community. Don't forget to follow our community to get the latest project updates!

2. Demographics

When we talk about growth, we talk about numbers! Here's a recap from January 14 to February 12.

2.1 New Members

Since January 15th we have doubled the number of members! Currently we have 2197 active members on the server and many of them are practicing English every day in voice channels (in groups or one-on-one) and text channels of different styles.

2.2 Members Activation

One of the metrics we'll be working on this month is the "activation" of a new member, which is when they understand what the community is about and why it's a good fit for them.

We did great in the first month and you can see the graph going straight to the bottom, but that's just because this last week we had Carnaval here in Brazil, so it was expected and our Brazilian developers deserve this amazing event and a good vacation.

2.3 Member Visits & Comunicators

Our average number of communicators or engagement is 8%. Our goal is to get to 15% by the end of March. How are we going to do that? I don't know yet, but with this list of weekly events, it should be a good bet.

3. Events

Events are at the heart of our community, and last month, 16 pre-scheduled events were held, divided into 5 models:

Basement Meeting: Our weekly meeting held every Tuesday at 07:00 PM BRT. Its purpose is to share the plans of our community, announce new partnerships, update members on news, and of course, practice English.
Practicing with Renato: Every Wednesday, our community gathers to practice English with Renato. In this practice session, our members are given a topic, and each one engages in a conversation with Renato about it, always introducing new words to expand the community's vocabulary.
Traveling with JP: In this session, our members will plan their dream trip together with JP, discussing costs, places to visit, local food, and much more! Come and plan your trip with us.
Practice with Leonardo: Every Thursday morning, our community participates in an English practice session with Leonardo. Participants are assigned a topic and engage in conversation with Leonardo, incorporating new words to build vocabulary.
Coding Dojo: In early February, we launched the Basement Coding Dojo, an event where community members take on roles in a development team during a simulated sprint. Our first Dojo Dev Team is made up of Gabriel, Lorena, Lucas, Pedro, Renato and Yuri. Over the course of a month, the team aims to build a simple but complete application, working on design, backend and frontend, attending weekly meetings and interacting with an open-source project. You can find more information about this event in this repository.

4. Partnerships

Right now our biggest goal is to find HR companies or even companies that are actively recruiting developers.

For this month, our goal is to build a demographic with more information about things that will be interesting to bring these opportunities to our members, e.g: Seniority, Stack and others. So far we have some results, but nothing that's meaningful yet, since it's a new approach on our side.

If you have an open position in your company, please email me at danielhe4rt@gmail.com and I'll forward it to our best members to apply!

5. Published Content

During the last month, members of our community have received several recognitions for the articles produced on this platform. We would like to highlight the following articles, which were among the most relevant articles of their posting weeks (Top 7).

Database 101: How to Model Leaderboards for 1M Player's Game.

Daniel Reis for ScyllaDB ・ Jan 29 '24

#scylladb #database #yarg #tutorial

"In the latest installment of his "Database 101" series, @danielhe4rt explores the intricate art of modeling leaderboards for games with a million players. Drawing on personal experiences with the open-source rhythm game YARG and leveraging ScyllaDB's efficiency, the article delves into Query Driven Data Modeling and wide-column database concepts, providing a comprehensive guide for crafting performative leaderboards."

Everything you need to know about GIT

Renato Teixeira for Basement Developers ・ Feb 5 '24

#beginners #tutorial #learning #git

"Discover the world of code versioning with GIT through this comprehensive beginner's guide! Authored by first-time DEV contributor @reenatoteixeira, this breakout article meticulously unpacks all the essentials of GIT, ensuring a smooth learning journey. With crystal-clear explanations and detailed step-by-step instructions, you'll master the art of GIT, empowering you with seamless version control capabilities."

Staircase detail

Klecianny Melo ・ Feb 16 '24

#tutorial #programming #beginners #learning

Discover how to build staircases in programming for beginners with this fantastic step-by-step tutorial created by our contributor @kebcm! A staircase is a visual representation formed by a series of steps, each represented by the # character. Explore how to create a function that prints a custom-sized staircase.

Be a better developer with these Git good practices

Anthony Vinicius for Basement Developers ・ Feb 16 '24

#git #github #webdev #beginners

If you're a developer, you likely use Git regularly. It's vital for app development, whether solo or in a team. But many struggle with messy repositories and unclear commit messages / branch names. Learning Git well and sticking to best practices is one of the keys for career growth.

6. What now?

So far our community is growing in a way we didn't expect, but still in a healthy way. Many people who have never tried Technical English before have taken their first steps to practice and have begun to glimpse new possibilities, and that's the fuel we need.

If you want to be a part of this transformative journey, please join our Discord Server and don't forget to like and comment on this article!

Any tip to make our community better is welcome, ok? Stay hydrate and see you next month!

Btw, cheers to Renato and Anthony for helping me on this report :D

Be a better developer with these Git good practices

Anthony Vinicius — Fri, 16 Feb 2024 20:44:23 +0000

If you're a developer, you probably use the versioning system called Git on a daily basis. The use of this tool is crucial for the development process of an application, whether working in a team or individually. However, it's common to encounter messy repositories, commits with unclear messages that don't convey useful information, and misuse of branches, among other issues. Knowing how to use Git correctly and following good practices is essential for those who want to excel in the job market.

Naming Conventions for Git Branches
Branch Names Convention Prefixes
Commit Message
Conventional Commit's

Naming Conventions for Git Branches

When we're working with code versioning, one of the main good practices that we should follow is using clear and descriptive names for branches, commits, pull requests, etc. Ensuring a concise workflow for all team members is essential. In addition to gaining productivity, documenting the development process of the project historically simplifies teamwork. By following these practices, you'll see benefits soon.

Based on it, the community created a branch naming convention that you can follow in your project. The use of the following items below is optional, but they can help improve your development skills.

1. Lowercase: Don't use uppercase letters in the branch name, stick to lowercase;

2. Hyphen separated: If your branch name consists of more than one word, separate them with a hyphen. following the kebab-case convention. Avoid PascalCase, camelCase, or snake_case;

3. (a-z, 0-9): Use only alphanumeric characters and hyphens in your branch name. Avoid any non-alphanumeric character;

4. Please, don't use continuous hyphens (--). This practice can be confusing. For example, if you have branch types (such as a feature, bugfix, hotfix, etc.), use a slash (/) instead;

5. Avoid ending your branch name with a hyphen. It does not make sense because a hyphen separates words, and there's no word to separate at the end;

6. This practice is the most important: Use descriptive, concise, and clear names that explain what was done on the branch;

Wrong branch names

fixSidebar
feature-new-sidebar-
FeatureNewSidebar
feat_add_sidebar

Good branch names

feature/new-sidebar
add-new-sidebar
hotfix/interval-query-param-on-get-historical-data

Branch Names Convention Prefixes

Sometimes the purpose of a branch isn't clear. It could be a new feature, a bug fix, documentation updates, or anything else. To address this, it's a common practice to use a prefix on the branch name to quickly explain the purpose of the branch.

feature: It conveys a new feature that will be developed. For example, feature/add-filters;
release: Used to prepare a new release. The prefix release/ is commonly used to do tasks such as last touched and revisions before merging the new updates from the branch master to create a release. For example, release/v3.3.1-beta;
bugfix: It conveys that you're solving a bug in the code and it's usually related to an issue. For instance, bugfix/sign-in-flow;
hotfix: Similar to bugfix, but it is related to fixing a critical bug present in the production environment. For example, hotfix/cors-error;
docs: To write some documentation. For example, docs/quick-start;

If you're working in a workflow with task management, like Jira, Trello, ClickUp, or any similar tool that can create User Stories, each card has a number associated. So, is commonly use these card numbers on the prefix of branch names. For example:

feature/T-531-add-sidebar
docs/T-789-update-readme
hotfix/T-142-security-path

Commit Message

Let's go talk about commit messages. Unfortunately, is so easy to find projects with commit messages like "added a lot of things" or "Pikachu, I choose you"... Yeah, I once found a project where the commit messages were related to a Pokémon fight.

Commit messages are really important in the development process. Creating a good history will help you a lot of times in your journey. Like branches, commits also have conventions created by the community, which you can learn about below:

A commit message has three important sections: Subject, Description, and Footer. The subject of a commit is required and defines the purpose of a commit. The description (body) is used to provide additional context and explanation for the commit's purpose. Lastly, there's the footer, commonly used for metadata like assigning a commit. While utilizing both the description and footer is considered a good practice, it's not required.
Use the imperative mood in the subject line. For example:

Add README.md ✅;
Added README.md ❌;
Adding README.md ❌;

Capitalize the first letter of the subject line. For example:

Add user authentication ✅;
add user authentication ❌;

Don't end the subject line with a period. For example:

Update unit tests ✅;
Update unit tests. ❌;

Limit the subject line to 50 characters, i.e., be clear and concise;
Wrap the body at 72 characters and separate the subject from a blank line;
If your body of commit has more than one paragraph, so use blank lines to separate them;
If necessary, use bullet points instead of only paragraphs;

Conventional Commit's

"The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history."

The quote below was obtained from the Conventional Commit's official website. This specification is the most used convention to commit messages in the community.

Structure

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Commit Type

The first structure that we have to study is the commit type. It provides a clear context about what's done in this commit. Below you can see the list of commit types and when to use them:

feat: Introductions of new functionalities;
fix: Rectifications of software bugs;
refactor: Employed for code alterations preserving its overall functionality;
chore: Updates not impacting production code, involving tool, config, or library adjustments;
docs: Additions or modifications to documentation files;
perf: Code changes enhancing performance;
style: Adjustments related to code presentation, like formatting and whitespace;
test: Inclusion or correction of tests;
build: Modifications affecting the build system or external dependencies;
ci: Alterations to CI configuration files and scripts;
env: Describes adjustments or additions to configuration files within CI processes, such as container configuration parameters.

Scope

A scope is a structure that can be added after the commit's type to provide additional contextual information:

fix(ui): resolve issue with button alignment
feat(auth): implement user authentication

Body

The body of a commit message provides detailed explanations about the changes introduced by the commit. It's typically added after a blank line following the subject line.

Example:

Add new functionality to handle user authentication.

This commit introduces a new module to manage user authentication. It includes
functions for user login, registration, and password recovery.

Footer

The footer of a commit message is used to provide additional information related to the commit. This can include details such as who reviewed or approved the changes.

Example:

Signed-off-by: John <john.doe@example.com>
Reviewed-by: Anthony <anthony@example.com>

Breaking Change

Indicate that the commit includes significant changes that may lead to compatibility issues or require modifications in dependent code. You can add a BREAKING CHANGE in the footer or include ! after the type/scope.

Examples of commits using conventional commits

chore: add commitlint and husky
chore(eslint): enforce the use of double quotes in JSX
refactor: type refactoring
feat: add axios and data handling
feat(page/home): create next routing
chore!: drop support for Node 18

With subject, body and footer:

feat: add function to convert colors in hexadecimal to rgba

Lorem Ipsum is simply dummy text of the printing and typesetting industry.

Lorem Ipsum has been the industry's standard dummy text ever since the 1500s.

Reviewed-by: 2
Refs: #345

References

Everything you need to know about GIT

Renato Teixeira — Mon, 05 Feb 2024 14:30:00 +0000

I'm sure you can imagine the importance of versioning code, so that we can revert changes and recover lost data among other possibilities.
I bet you know someone (not me hehe) who does version control with their files by creating copies of them with increasingly creative names...

This was probably how anyone would do version control with their code as well before 1972, with the release of SCCS (Source Code Control System), one of the first centralized version control software ever released.

But we're not here to talk about SCCS, what really interests us now is GIT, the distributed open-source version control software that celebrates its 20th anniversary next year (07/04/2005).

1. What's GIT?
2. How does GIT work?
3. Installing GIT
4. Configuring GIT
5. Starting a local repository
6. Working with GIT
7. Knowing branches
8. Syncing with the remote repository
9. Conclusion
10. References

1. What's GIT?

GIT is an open-source distributed version control system launched in 2005 and developed by Linus Torvald (yh, the Linux kernel creator).

With GIT, we can locally control the versions of a project (in the working folder) and synchronize all changes to a remote repository (on GitHub, for example).

2. How does GIT work?

Imagine a physical file cabinet where there's a folder with all the project files. Whenever someone needs to manipulate a file, they have to pick it up, removing it from the folder and returning it to the folder after finishing. So, it is impossible for two people to work on the same file, completely avoiding any possible conflicts.

BUT THAT'S NOT HOW GIT WORKS! (thank God)

This is how a CENTRALIZED version control system works, in which the user needs to "check-out" and "check-in" files, i.e. whenever someone needs to work on a specific file, they need to check-out that file, removing it from the repository, and then check-in the file once the work is done, returning it to the repository.

In a DISTRIBUTED system like GIT, it's possible for several people to access files from the same remote repository. Whenever someone needs to manipulate a file, they can simply clone it (or clone the entire repository) locally to their machine, and then send the modifications back to the remote repository. This makes it possible for several people to work on the same project, even manipulating the same files.

This is what allows the distribution of large open-source projects, with people from different parts of the world working on the same project, managing modifications and possible conflicts (yes, merge conflicts can happen here).

3. Installing GIT

GIT is available for the main operating systems (Windows, Linux, MacOs...) with a very simple installation process, which can be done by command line or through the official installer at git-scm.com.

3.1 On Windows

To install GIT on Windows, simply go to the official website and download the installer. Then just follow the instructions and everything should be fine then we'll be able to use the GIT commands in our terminal.

3.2 On Linux

For Linux, we can install GIT using the command below:

sudo apt install git-all

By doing this, GIT must be ready to run in our terminal.

3.3 On MacOS

For Mac, the easiest way to install GIT is to install Homebrew and then run the command below in the terminal:

brew install git

Then GIT must be ready to run in our terminal.

4. Configuring GIT

After installing, it's important to configure GIT with the commands below:

git config --global user.name "[username]"
# e.g. John Doe

git config --global user. email "[email@email.com]"
# e.g. johndoe@email.com

Also, it's possible to configure specific users for certain local repositories by removing the --global tag.

5. Starting a local repository

With GIT configured, we can start our local repository. To do this, we can start a new repository from scratch or clone an existing remote repository.

5.1 Starting from scratch (git init)

To start a new repository, simply navigate to the desired repository root folder and run the command below:

git init

By doing this, a .git directory will be created inside the project folder, which will be responsible for the version control in the working folder of this local repository.

5.2 Cloning an existing repository (git clone)

Cloning an existing remote repository is as easy as starting a new one from scratch. To do this, simply use the git clone command, with the remote repository URL to be cloned inside the folder where we want to download the repository:

git clone [repository-url]

Then the entire repository must be cloned to our local machine and automatically linked to the related remote repository.

With a cloned repository, we will no longer need to use the git remote command in the future.

6. Working with GIT

Within our local repository, we can create the files needed for our project, but they won't be automatically synced by GIT, we'll need to report it when there are any changes to be versioned.

Thus, we can manipulate the files as we wish and after finishing the desired changes, send the updated files to GIT.

To do this, it is important to understand that there is a 3 stage infinite flow (yes, infinite) in version control:

              MODIFY -> STAGE -> COMMIT

MODIFY: The first stage of version control, this is where we find the files that have changed compared to the last available version.
STAGE: The second stage of version control, this is where we place modified files that we want to add to our next commit.
COMMIT: Final stage of version control, when we confirm the changes, sending the modified files that were in stage to the local repository.

After committing the modified files, we have a new version available in the local repository, which can again receive updates, going one more time to "modified", then placed in "stage" and, again, being "committed", confirming a newer version and so on (and therefore, "infinite" lol).

It's important to notice that a commit doesn't overwrite the old version of the modified files, but includes the new version with a pointer to the last version, thus keeping track of the versions of each file tracked by GIT.

6.1 Adding and commiting (git add and git commit)

Although it might sounds complex, performing the version control flow is very simple. Since the desired modifications are completed, we add the modified files that we want to commit on stage with the command below:

git add [filename]

git add -A -> adds all modified files to stage at once.

git add *.[extensão-do-arquivo] -> adds all modified files with the specified file extension to stage at once (e.g. git add *.html)

We can check our current local repository status at any time using the git status command:

Note that when we run git status inside the repository after creating a new file, the new file is shown as "Untracked". This means that this file is fresh new and still needs to be added to any commit in order to be tracked by GIT.

It's possible to let GIT ignore specific files or folders within the repository. To do this, we can simply add a file to the root folder called .gitignore and write the name of the files or folders that should be ignored inside it.

CAUTION: Ignored files and folders will no longer appear to the GIT track, not even as "Untracked". To reset the tracking, simply delete the desired names from the .gitignore file.

To include a file, we can run the git add command with the name of the file that we want to add ("index.html" in this case):

This way, by re-running git status we can see that the new file has been added to "stage" and is finally ready to be sent in our next commit, which can be done using the command below:

git commit -m "[descriptive-message]"

Commits have unique IDs (hash codes) and are IMMUTABLE, i.e. they cannot be modified once they have been confirmed.

git commit -a -> performs a direct commit, adding all the modified files to stage and committing them.

After successfully committing a file, when running git status we notice that there are no more modified files to be uploaded, since all the modifications were effectively saved in our local repository with our last commit.

Also, it's possible to verify the changes made by reviewing the repository's commit log, using the git log command, which shows some metadata of all the commits made, such as the hash code, branch, author, date, etc.

This whole process can be repeated to add new files that are needed for our project, modify them and send them to the local repository by making new commits.

git log -N -> displays a log with the last N commits.

git log [branch-A] [branch-B] -> displays a log of commits that are in "branch-B" but not in "branch-A".

git log --follow [filename] -> displays a log of commits that changed the specified file, even if it has changed its name.

git diff -> lists the changes made compared to the latest available version in the repository.

git diff [nome-do-arquivo] -> lists the changes made to the specified file in relation to its last available version in the repository.

6.2 Undo changes before and after commiting

Before a commit is made, any changes made to the local repository can be undone or changed, but once the commit is made, it cannot be changed. This is because commits are immutable objects, meaning that it is impossible to edit or change the data in a commit.

However, it is possible to make new commits that undo changes, or correct incorrect information in previous commits. In either way, we can use one of the commands below:

git checkout -- [filename]
# Discards changes made to the local file before the commit (irreversible action)

git reset --hard HEAD
# Discards changes made to a file that is in stage (before the commit)

git reset --hard HEAD~1
# Discards the last commit made in the local repository (only the last commit)

git commit --amend
# Creates a new commit, replacing the last commit made in the local repository

git revert [commit-hash]
# Creates a new commit, reverting the changes of the specified commit

7. Knowing branches

A branch is nothing more than a ramification of the repository, and so far all actions have been performed on the branch master/main'.

By default, the first branch created in the repository is the master/main, which is the main branch of the repository.

7.1 Why use branches?

It may not seem like much at first, but branches give enormous power to the project development.

Imagine we're developing a web platform, and we want to test a new feature, but our repository is already hosted or shared with other people, and any problematic change could cause a bad experience for them. What can we do?

If you've been thinking about copy and paste the project folder, creating a new "test version", you're right! Well, almost...

With GIT, we can do something similar with branches. Since they are branches, we can simply create a new branch called "test", and thus have a version of our project in a completely isolated branch, ready to be flipped without risking the main branch.

7.2 Creating branches (git branch)

Creating a branch means creating a parallel copy of the repository that can be worked on independently, without affecting the master/main branch. To do this, we can simply run the command below:

git branch [branch-name]

Running the git branch command without a specific branch name must display the list of available branches in the repository, with a "*" marking the branch that's currently in use.

Before running the git branch test command, the git branch command only returned the master branch.

After creating a new branch, we can run the command below to switch between the available branches:

git checkout [branch-name]

After running the git checkout test command we can see that the active branch is switched. From that moment on, all committed information will be sent to the test branch of the repository, without affecting the branch master/main.

It's possible to create as many branches as we need, and we can interact with the existing branches using the commands below:

git checkout -b [branch-name] -> creates a new branch with the given name and directly switches to it.

git branch -d [branch-name] -> deletes the specified branch.

git branch -m [new-name] -> changes the name of the current branch to the given name.

7.3 Merging branches (git merge)

When finished working on a different branch, and we're sure that the changes we've made haven't caused any problems in the project, we can merge the current branch in the master/main branch, applying all the changes from the current branch to the main branch of the repository.

To merge branches, we need to switch to the branch that will receive the changes and run the following command:

git merge [branch-name]
# Merge the given branch into the active branch

Here, since we are on the branch test, we should switch to the branch master using the git checkout command, and then run the git merge command with the name of the branch we want to merge ("test", in this case).

By doing this, all the work done on the branch test (in this case, the creation of the style.css file) will be merged in the branch master.

7.4 Merge conflicts

Merging different branches with git merge can lead to some conflicts in cases where one or more files have been changed on the same lines and the merge cannot be done automatically.

When this happens, we can run the git status command to check which files are in conflict.

We'll need to solve the conflicts before proceeding with the merge, either by defining which changes should take place, or by reviewing the changes so that they are mutually compatible. To do this, GIT will insert markers into the conflicting files to help with the resolution.

After solving the conflicts, we just need to put the modified files back on stage, commit the new no-conflict versions, and run the git merge command again, which must successfully merge without any problems.

8. Syncing with the remote repository

We already know that it's possible to connect our local repository to a remote repository and synchronize all our work remotely, keeping it up to date.

To do this we'll need to run the git push command, which sends all commits from the local repository to the remote repository, but first we need to **configure a remote repository.

8.1 Configuring the remote repository

Starting a remote repository is quite simple. Here we'll use GitHub to do it.

First, we need to start a new empty repository in our GitHub account (just by choosing a name and clicking "Create repository"):

Next, we need to configure the relationship between the remote repository and the local repository by running the following command inside our local repository:

git remote add origin [remote-repository-url]

git remote -v -> shows the URL of the remote repository that's actually connected to the local repository.

With the remote repository properly connected, we need to change the name of our local branch master/main to "main" with the command git branch -m main (ignore this step if your local branch is already called main):

It's important to keep the main branch of the local repository with the same name as the main branch of the remote repository to which we are pushing.

Finally, after completing the above steps, we can sync our local repository with the remote repository for the first time using the following command:

git push -u origin main

When we run the git push -u origin main command, we may need to enter our GitHub credentials (user and access token).

If you don't know what a GitHub access token is, or you don't have one access token set up, click here.

We can also work around this by configuring authentication using the GitHub CLI. Find out how by clicking here.

After authenticating, git push should run successfully, synchronizing all commits in the local repository with the remote repository.

8.2 Git push after the first time (git push)

After going through all the above steps, new syncs can be done using the git push command alone, without any additional parameters, like shown below.

In this case, the authentication needed to run the command git push was bypassed using the GitHub CLI. You can find out how by clicking here.

8.3 Updating the local repository (git pull)

With a distributed remote repository, it's possible for changes to be made remotely (directly in the remote repository), causing our local repository to become outdated.

Thinking about that, it's very important to update the local repository and sync any changes that we got in the remote repository, ensuring that the local project is always with the latest version available in the remote repository. To do this we can run the following command:

git pull

Imagine that a new file README.md has been created directly in our remote repository and because of that our local repository is now outdated.

Within the local repository we can synchronize the changes from the remote repository using git pull as mentioned above.

The first 7 lines returned when we run the git pull command are the return of the git fetch command. In other words, if we run the git pull command without first running the git fetch command, GIT will run both together to retrieve the updates from the remote repository and synchronize them to the local repository.

git fetch -> fetch updates from the remote repository, but does not sync the local repository (requires git pull).

9. Conclusion

All this leads us to the certainty that GIT is a version control system that is necessary in the daily life of a programmer, and knowing its main commands and uses can be the turning point in our technical seniority. Finally, with the local and remote repositories synced and updated and with everything we've learned so far, we're ready to move forward with the practicality of this awesome version control system.

10. References

I'm creating a new tech community

Daniel Reis — Mon, 15 Jan 2024 15:01:52 +0000

What's up folks! I'm here to recruit the coolest people to join my new community.

Recently I decided to step down from my previous community, He4rt Developers (PT-BR) community and start a new thing focused in the international environment.

Yet Another Tech Community

First weekly community meeting with a peak of 54 members

The community is called Basement Devs, a community focused to help people to achieve better opportunities in Europe mostly (US can be a thing as well).

Why I decided to start that: I want to give more people a safe place to practice English and get better opportunities around the world through my network with the Microsoft MVP program, Developer Relations communities, and tech events I'm currently attending.

I've been working with communities for 5 years so far, but this is the first time I've trying to make this a global thing, so it would be cool to have more people join us!

So far the community has 1,160 members and 1 week of existence and most of the members are mid/senior level, Brazilians, from all possible backgrounds and stacks who want to mentor a non-Portuguese speaker (any level) to practice their English.

Also if you know anyone that wants to learn about programming, we'll be really glad to help them!

So what? Who can join us?

If you're starting at programming or is already at the market and looking for guidance, our community is what you're looking for!

We have members that works in huge companies like X-Team, Spotify and GitHub (among many others) that will gladly help you when possible!

And if you're in university, it will also be a cool thing for you to share some of your problems and solutions for specific classes.

The only thing that we ask you for is to respect the community rules and the Discord guidelines.

Next Steps: stick together ft. Rust!

Our focus is on the Discord community, and I also decided to use this fresh start to learn more about Rust. So all the tools/bots/whatever we're going to build there will use it.

Also I already scheduled a weekly growth meeting, a very special moment to understand from the community what will be our next steps and also bring some good news! This meeting happens every Tuesday at:

5PM (EST)
7PM (BRT)
11PM (CET)

... so feel free to join us if possible!

Usually I do 6h at least of LiveCoding at Twitch and I'm getting at least 1h to discuss about the community together with the members, so, feel free to join us there as well!

Anyway, thanks for reading this until now and welcome to our community!

Link to Discord Community
Link to Twitch Channel
Link to Twitter Profile

DEV Community: Basement Developers

Database for newbies: Hands On

Table of contents

Hands on!

Preparing the environment

Creating our first database

Datatypes and Properties

CRUD

Create

Read

Update

Delete

And that's it!

Database for newbies: Theorethical Approach

Table of contents

What is database?

Types of database

Relational

Non relational

What is SQL?

And that's it!

Protocols and how they work

OSI and TCP/IP stack

Ok, but what these layers actually do?

To be continued...

References

What we've achieved with 1 Month of Basement Devs

Table of Contents

1. General Achievements

2. Demographics

2.1 New Members

2.2 Members Activation

2.3 Member Visits & Comunicators

3. Events

4. Partnerships

5. Published Content

Database 101: How to Model Leaderboards for 1M Player's Game.

Daniel Reis for ScyllaDB ・ Jan 29 '24

Everything you need to know about GIT

Renato Teixeira for Basement Developers ・ Feb 5 '24

Staircase detail

Klecianny Melo ・ Feb 16 '24

Be a better developer with these Git good practices

Anthony Vinicius for Basement Developers ・ Feb 16 '24

6. What now?

Be a better developer with these Git good practices

Table of contents

Naming Conventions for Git Branches

Branch Names Convention Prefixes

Commit Message

Conventional Commit's

Structure

Commit Type

Scope

Body

Footer

Breaking Change

Examples of commits using conventional commits

References

Everything you need to know about GIT

Table of contents

1. What's GIT?

2. How does GIT work?

3. Installing GIT

3.1 On Windows

3.2 On Linux

3.3 On MacOS

4. Configuring GIT

5. Starting a local repository

5.1 Starting from scratch (git init)

5.2 Cloning an existing repository (git clone)

6. Working with GIT

6.1 Adding and commiting (git add and git commit)

6.2 Undo changes before and after commiting

7. Knowing branches

7.1 Why use branches?

7.2 Creating branches (git branch)

7.3 Merging branches (git merge)

7.4 Merge conflicts

8. Syncing with the remote repository