Forem: Lucas Rafaldini

Conselhos para Startups

Lucas Rafaldini — Mon, 27 Oct 2025 16:36:00 +0000

post de 03/12/2013, por Sam Altman

Tradução para o português por Lucas Rafaldini

Em homenagem à nova turma da Y Combinator que começa amanhã, aqui estão alguns dos melhores conselhos para startups que recebi ou dei (na maior parte, recebi):

Faça algo que as pessoas realmente queiram;
Uma ótima equipe e um ótimo mercado são igualmente criticamente importantes — você precisa dos dois. O debate sobre qual é mais importante é tolo;
Escreva código, converse com usuários e construa a empresa (contrate as melhores pessoas que puder, acerte na cultura, levante investimento, feche vendas, etc.). A maioria das outras coisas que fundadores fazem é perda de tempo;
Defina uma visão clara e fácil de entender para sua empresa e faça disso uma missão na qual as pessoas realmente acreditem;
Mantenha o foco e não tente fazer muitas coisas ao mesmo tempo. Preocupe-se com a qualidade da execução;
Você precisa de um nível quase insano de dedicação à sua empresa para ter sucesso;
Em geral, não comece uma startup na qual você não estaria disposto a trabalhar por dez anos;
Seja implacavelmente cheio de recursos (engenhoso);
No mundo atual, cheio de “pivôs”, boas ideias são subestimadas. Vale a pena dedicar tempo para pensar em uma boa;
Crescimento resolve (quase) todos os problemas;
Embora o crescimento seja crítico e você deva focar nele, pense ocasionalmente para onde está indo — é preciso crescer em direção a algo valioso;
Seja obcecado pela qualidade do produto;
Comunique-se demais com sua equipe. Por algum motivo, a maioria dos fundadores é realmente ruim nesse aspecto. A transparência é sua aliada;
Mova-se rápido. A velocidade é uma das suas principais vantagens sobre grandes empresas;
Contrate devagar; demita rápido. Contratar é a coisa mais importante que você faz — dedique pelo menos um terço do seu tempo a isso;
Pense, de tempos em tempos, por que a vigésima pessoa se juntaria à sua empresa;
Contrate pessoas inteligentes e eficazes que estejam comprometidas com o que você está fazendo. As últimas sete palavras são importantes;
Contrate amigos e amigos de amigos. Vá atrás dessas pessoas com tudo. Outras fontes de contratação são boas, mas eu sempre tive resultados ruins de recrutadores técnicos;
Valorize aptidão mais do que experiência;
Contrate pessoas que você poderia descrever como um animal;
Elimine distrações;
Não morra;
Seja frugal (moderado, simples, sóbrio e/ou discreto);
Você frequentemente ouvirá conselhos conflitantes sobre tudo, exceto “construa um ótimo produto”. Isso significa que você pode seguir qualquer caminho na maioria das outras coisas e realmente não importa. Apenas tome uma decisão e volte ao trabalho. Adequação de produto/mercado é o que importa. Você pode – e irá – cometer um monte de erros;
Você cria aquilo que mede;
Startups são muito difíceis de qualquer forma; portanto, é melhor mirar em uma grande oportunidade;
Momentum é tudo. Não o perca;
Mantenha salários baixos e participação acionária alta;
Mantenha a organização o mais horizontal possível;
Ao negociar — levantar fundos, fechar parcerias etc. — crie uma situação competitiva;
“Schleps” (tarefas maçantes e inevitáveis) são boas;
Não se esqueça de ganhar dinheiro;
Jornalistas gostam de ouvir diretamente dos fundadores;
É padrão que fundadores mantenham o controle do conselho na primeira rodada;
Ouça todo mundo. Depois, tome sua própria decisão;
Lembre-se que é mais provável morrer por má execução do que ser esmagado por um concorrente;
Dê sorte;
Tenha uma relação direta com seus clientes;
Seja formidável — não seja fácil de intimidar;
Não deixe sua empresa ser comandada por um vendedor. Mas aprenda a vender seu produto;
Tenha uma cultura que recompense resultados;
Não contrate gerentes profissionais cedo demais;
O simples é bom. Desconfie da complexidade;
Em situações especiais, pegue um avião. O presencial ainda é melhor;
A maioria das coisas não é tão arriscada quanto parece;
Desconfie de quem fala “processo” demais;
Levante um pouco mais de dinheiro do que acha que precisa;
Ignore o fato de que “a imprensa te ama”;
Tenha um ótimo atendimento ao cliente;
Você pode criar valor através de inovação extrema, refinamento progressivo ou coordenação complexa. Grandes companhias geralmente fazem duas dessas coisas. As melhores companhias fazem as três;
O papel do conselho é aconselhar e aprovar. Se o CEO não define a estratégia e tenta fazer com que o conselhor a defina, tende a terminar em desastre;
Observadores de conselho geralmente são dor de cabeça;
Se for pivotar, faça isso completamente e com convicção. A pior coisa é tentar fazer um pouco do que é velho e um pouco do que é novo – é difícil matar seus bebês;
É melhor tomar uma decisão e errar do que hesitar;
Defina metas e motive as pessoas a alcançá-las;
Sempre elogie um bom trabalho;
Celebre as vitórias como companhia. Consiga camisetas para cada grande milestone;
Tenha uma boa cadência operacional na qual projetos são curtos e você está sempre lançando algo novo com recorrência;
Você pode vencer com o melhor produto, o melhor preço ou a melhor experiência;
Meetups e conferências geralmente são perda de tempo;
Se os fundadores parecem se importar mais em ser fundadores do que com a empresa, vá para outra;
É mais fácil vender analgésicos do que vitaminas;
Desconfie de trabalho que não envolva construir produto ou conquistar clientes. É fácil ser puxado para dentro de uma espiral mortal de reescrita de infrastrutura;
É melhor ter poucos usuários que amem seu produto do que muitos que apenas gostem;
Aprenda a manter-se otimista mesmo quando tudo estiver desmoronando;
Startups deveriam precisar de quanto menos milagres for possível — mas precisam de pelo menos um;
Você precisa ter uma ótima execução. Muito mais gente tem boas ideias do que gente que arregaça as mangas e faz acontecer;
Não busque diversidade cultural no início;
Faça uma lista de tarefas diária. No topo dela, coloque uma ou duas grandes coisas nas quais você quer trabalhar;
Ser CEO é miserável mais vezes do que é bom. Mas quando é bom, é ótimo;
Nos dias ruins, lembre-se de que amanhã será melhor. É difícil que seja muito pior!;
Durma e se exercite;
Sucesso em startups é geralmente sinônimo de "passa ou falha". Preocupe-se mais em assegurar-se de passar do que em um ponto extra de diluição;
Bons investidores merecem um premium razoável;
Dê algo para seus investidores fazerem;
Prefira poucos investidores engajados a muitos distantes;
Levante dinheiro com promessa e termos limpos;
Faça checagem de referência com seus investidores potenciais. Questione outros fundadores sobre eles antes que tudo desande;
Investidores amam empresas que outros investidores amam;
Muitas boas ideias parecem ruins no início. Você precisa de uma ideia que está na intersecção entre "parece uma má ideia" e "é uma boa ideia". (É importante notar que você precisa ser contrariador e certo, não apenas contrariador.);
Surfe na onda de alguém;
Às vezes, você pode vencer através de pura força de vontade;
Toda startup está ferrada em pelo menos uma grande maneira. Continue;
Mantenha um olho no dinheiro no banco e não deixe ele acabar;
Preste muita atenção à relação entre os cofundadores, especialmente se ambos/todos querem ser CEO;
Mantenha-se pequeno e ágil;
Faça uma reunião de equipe por semana;
Encontre um mentor que te ensine a gerenciar;
Mantenha o burn rate baixo até ter certeza de que tudo funciona;
Desconfie de comprar usuários;
Lidere pelo exemplo;
Tenha o tipo certo de escritório. O escritório adequado para uma companhia muito pequena é um apartamento ou uma casa;
Compartilhe métricas e resultados com a equipe todo mês;
Tenha uma tabela em suas cartas de oferta que mostre quando a ação que você está oferecendo hoje vai se valorizar em diferentes cenários;
As melhores startups são definidas por exceções; todas essas regras são provavelmente quebráveis, mas provavelmente não todas ao mesmo tempo.

Créditos

Texto original: “Startup Advice”, por Sam Altman.

Tradução: Lucas Rafaldini

Publicado originalmente em inglês no blog de Sam Altman.

Tradução e adaptação autorizadas para fins educacionais e de divulgação.

✍️ Publicado em lucas.rafaldini.github.io.

Back to Basics #3 - Databases and SQL Fundamentals

Lucas Rafaldini — Wed, 17 Jan 2024 13:37:00 +0000

In the digital world, data is the new gold, and knowing how to efficiently store, retrieve, and manipulate this data is a crucial skill for any developer. That’s where databases and SQL come in. In this installment of our Back to Basics series, we dive into the fundamentals of databases and the language that helps us communicate with them - SQL (Structured Query Language).

What is a Database?

A database is an organized collection of data. It’s like a digital filing cabinet where data is stored in a structured way so that it can be easily accessed, managed, and updated. Databases can range from simple, like a contact list on your phone, to the complex, like the massive databases that run social media platforms.

Types of Databases

Relational Databases (SQL): These databases organize data into tables linked by relationships, making data management more efficient. Popular examples include MySQL, PostgreSQL, and SQLite.
Non-Relational Databases (NoSQL): These are used for unstructured data and are more flexible in terms of data storage. They include document-oriented databases like MongoDB and key-value stores like Redis.

Why SQL?

SQL is the language used to interact with relational databases. It allows you to:

Create and manipulate databases and tables.
Insert, update, and delete data.
Retrieve data according to complex criteria.

Basic SQL Commands

SELECT: Retrieve data from a database.

SELECT * FROM users;

INSERT: Add new data to a table.

INSERT INTO users (username, email) VALUES ('john_doe', 'john@example.com');

UPDATE: Modify existing data.

UPDATE users SET email = 'new_email@example.com' WHERE username = 'john_doe';

DELETE: Remove data from a table.

DELETE FROM users WHERE username = 'john_doe';

Understanding SQL and Databases

Mastering SQL and understanding databases are fundamental for back-end development, data analysis, and even in many other non-developer roles that require data manipulation. As we progress in our Back to Basics series, we’ll explore more about how to effectively use SQL in real-world scenarios and understand the power of databases in the tech world.

Stay tuned for more insights and foundational knowledge in tech. Let me know in the comments if there’s a particular topic you want to be covered in this series!

See you in the next post!

Guia de Análise de Tráfego para GitHub Pages: Integração com Ferramentas de Analytics

Lucas Rafaldini — Fri, 03 Nov 2023 07:15:06 +0000

Guia de Análise de Tráfego para GitHub Pages: Integração com Ferramentas de Analytics

Quando se trata de hospedar um site estático, o GitHub Pages é uma escolha popular entre desenvolvedores e criadores de conteúdo. No entanto, uma funcionalidade frequentemente solicitada é a capacidade de rastrear e analisar o tráfego do site. Este guia detalhado oferece soluções eficazes para integrar ferramentas de analytics ao seu site no GitHub Pages, permitindo que você obtenha insights valiosos sobre seus visitantes.

Como Integrar o Google Analytics ao Seu Site no GitHub Pages

O Google Analytics é uma ferramenta robusta que pode ajudar você a entender melhor o comportamento dos usuários em seu site. Siga estes passos para adicionar o Google Analytics ao seu GitHub Pages:

Crie uma conta no Google Analytics e configure uma nova propriedade para o seu site.
Obtenha o ID de acompanhamento e insira o seguinte snippet de código na seção dos seus arquivos HTML:

<!-- Código de acompanhamento do Google Analytics -->
<script async src="https://www.googletagmanager.com/gtag/js?id=SEU_ID_AQUI"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());

  gtag('config', 'SEU_ID_AQUI');
</script>

Verifique a instalação visitando seu site e conferindo se as visitas aparecem no painel do Google Analytics.

Plausible Analytics: Uma Alternativa Focada na Privacidade

Para aqueles preocupados com a privacidade dos usuários, o Plausible Analytics oferece uma solução leve e respeitosa à privacidade. A configuração é simples:

Registre-se no Plausible e adicione seu site.
Coloque o script fornecido na tag do seu site.

Fathom Analytics: Análise Simplificada

O Fathom Analytics é uma alternativa paga ao Google Analytics que se destaca pela simplicidade e foco na privacidade. A configuração é direta e semelhante ao Plausible.
Implementando o Código de Análise

Para adicionar qualquer uma dessas ferramentas de analytics ao seu site no GitHub Pages, você precisará:

Editar o template HTML ou páginas individuais, adicionando o código de rastreamento à seção .
Fazer commit e push das alterações para o seu repositório no GitHub.
Monitorar o painel de analytics para garantir que o tráfego esteja sendo rastreado corretamente.

A integração de ferramentas de analytics ao seu site no GitHub Pages é essencial para entender o comportamento do usuário e otimizar seu conteúdo. Com este guia, você pode facilmente configurar o Google Analytics, Plausible ou Fathom para começar a rastrear as métricas do seu site hoje mesmo.

Back to Basics #2 - Git Basic

Lucas Rafaldini — Tue, 23 Jun 2020 00:13:37 +0000

There was a time when developers didn't control very well changes made by an entire team on a project. I did not live that time and I believe you have not lived it either. However, many companies today still suffer to implement version control of the software produced by the development team. Folders like "Final", "Final 2.0", and "FINAL FOR REAL THIS TIME" still exist on many development teams and that is sad to say the least. For this reason, it is essential that developers know how to do this version control in the right way, understanding that controlling changes in the work and recording who made each change in the right way is a piece of cake.

Knowing Git

Git is currently the most widely used version control system in the world. This is due to its ease of use, to how lean it has been since its development and also because it is a native technology on all machines that run a linux kernel. In fact, Git is an invention of our friend Linus Torvalds and arose out of a real need (as all good ideas emerge): as soon as Linux stopped being just an individual project and Linus decided to share it with some friends, many changes in files did not make sense or, at least, did not feel like it at first glance. For Linus, this demonstrated some important needs when working as a team on that project that he loved:

It is necessary for the developer to add some kind of explanation for the change that was made so that no one gets lost when seeing a changed and possibly unreadable code;
It is necessary that the change is recorded with its date, a history of the old data compared to the new data and who is responsible for that change;
It is necessary that these changes if they are interpreted as unimportant or unproductive, can be discarded without harming the legacy code, or simply what was there before the change;

With that in mind, Linus created Git. Git separated the legacy code into a priority branch, requiring each developer, wishing to make a change, not to change that branch directly, but to copy a new branch in which he would include his modifications and, later, submit a request for merge with the priority branch. That way, he would be able to control the legacy code and choose for himself what should and shouldn't be changed in his code.

The tree metaphor

Perhaps it is a little difficult for some people to understand the concept of branch. For English speakers, the metaphor is a little more intelligible, as it applies to other areas, as in the case of companies that have headquarters (head offices) and offices (branches), but the thing is very simple to understand:

In the example above, we see in blue what the priority branch would be. After its second version, a developer wants to program a new feature or a fix. What it does is open a second branch, represented in purple. Thus, both the priority branch does not need to stop its advance hoping that this new functionality will get out of the way in the workflow: both evolve in parallel. The same process can be seen later in the example shown in green.

An essential fact to understand the Git version control that is not shown in the image is the aforementioned merge. Merge occurs when the developer finishes the functionality he had in mind when developing his branch. The objective is to make this functionality enter the legacy code, in the priority branch. Merge can be understood as a blend, a process that keeps what's there and inserts what's new without breaking everything.

Thus, we can see that version control behaves following the metaphor of a tree, in which there is a trunk (the priority branch) and for each change, a branch is created that carries with it all the properties of the tree to which it belongs.

What about Github?

Github is a web interface for viewing the flow of Git. It is something like a social network for controlling and viewing Git repositories and version controls that previously were only on one machine or on a private network of users. We can say that Github is for Git as Wix is for Front End development. It allows this technology that was made thinking about enabling and improving collective software development to be even broader, more collaborative, and easier to use.

Hands-on

Now that you know a little more about why Git exists and its importance for a developer, it's time for you to get your hands dirty and unlock your skills with Git (and Github) once and for all!

First, if you don't already have a Github account, create now at Join Github.

Repositories

Repositories can be local or remote. Local means that it is being saved on your machine, with version control registered on your computer. A remote repository is a code repository that has its version control and branches stored in an online repository distribution and control portal, such as Github, GitLab or BitBucket. By copying a remote repository, you can join the workflow of a new or ongoing project, bringing to your computer the code of all branches that you are authorized to access and change.

Adding remote repositories

As already mentioned, remote repositories are versions of projects that are stored somewhere on the internet. Adding a remote repository is basically telling your Git where your code is being stored. You can add it using the URL for the repository (or for some user's fork).

git remote add <name> <repository-url>

The ** name ** is a unique remote repository name on your machine. It can be anything, but it necessarily needs to be different from other names you've already given for repositories you've already added.

To see the list of remote repositories you have already added, run the following command:

git remote -v

Changing remote repositories

You may want to change the URL assigned to any of the remote repositories you have added.

To do this, use the following command:

git remote set-url <valid-repository-name> <new-url>

Remember to run git remote -v after changing the URL to confirm that your change worked.

Creating a branch (locally and remotely)

Then you choose a repository (or create it) and want to start coding. Okay, but before that you need a branch to call yours. To create a branch locally, run the following command:

git branch <new-branch-name>

Next, check if your branch is listed among your branches with

git branch

To change work branch, just run

git checkout <branch-name>

To simplify the job and you don't have to create a new branch and do the checkout with two commands, just use the following command:

git checkout -b <new-branch-name>

Cool, now your new branch is created locally! Now, assuming you've made some pretty cool changes to the code and want to upload a Pull Request, you just need to execute the following commands:

git add .
git commit -m 'Your commit description'
git push origin <branch-name>

The first command (add) adds the changed files to your commit, the point indicates that all changed files should be added to commit. If you want to add only one or more changes, just add the file path for the change. In case you don't remember the path, just use the command that lists all the changes:

git status

The second command (commit) creates a new commit for your branch. The - m flag is for you to add the commit message directly in the same command, which is the parameter that follows next between single quotes.

Deleting a branch (locally e remotely)

To delete a local branch, there is no secret. Just use the command::

git branch -d <branch-name>

Always remember to confirm that the branch was actually deleted using git branch.

To delete a remote branch, just use the following commando:

git push origin --delete <branch-name>

Remembering that for Git, _ origin_ indicates the origin of this repository, that is, the repository that is online, while its copy is remote. That is why the reference origin is used.

Undo a commit

To undo a commit locally, just use the command git reset. For example, if you want to undo your last commit, run the following command:

git reset --soft HEAD~1

The --soft flag keeps changes made to files you added to commit, only commit is reversed. However, if you prefer to revert commit and the changes made and added to it, run this command in place of the previous one:

git reset --hard HEAD~1

The parameter HEAD~1 points to your last commit. If you prefer to undo any previous commit, you can use the command _ git reflog_ to have a record of all previous commit. Having access to the previous commits, just use the same command reset replacing HEAD~1 with the hash referring to the commit that you want to undo:

git reset --soft <commit-hash>

To undo a remote commit, you can use the command git revert to undo the commit locally and then push changes to the remote branch.

To do this, first run reflog and then revert:

git reflog
git revert <hash-do-commit>

Finally, push it to the desired remote branch.

Did you like the article? Do you think there was a missing question to be addressed?

Please comment and let me know if this content helped you in any way.

See you later, aligator!

Originally posted in Portuguese here

Back to Basics #1 - The HTTP Protocol

Lucas Rafaldini — Wed, 03 Jun 2020 04:50:56 +0000

To start posting on this blog, I decided to start a series of posts on topics that are basic, but essential for beginning developers. As a first topic, I thought it would be cool to talk about the famous HTTP that everyone uses and few people understand. So, let's go to the guts of the protocol.

What is a protocol?

Do you remember when someone called you to a party and it's a costume party? Do you know remeber when someone said that, for instance, a judge or a POTUS should not use bad words (at least, not in public)? This is what we call "decorum" and, roughly speaking, we can say that this is a social protocol. A protocol is basically something that everyone agrees without saying anything explicitly, so it is understood by everyone that things must happen one way and only this way, or they will not happen at all.

Bringing this concept to the Web, the HTTP protocol (acronym for Hyper Text Transfer Protocol) is an agreement that establishes a decorum for the transfer of data between Clients and Servers, so no one speaks different "languages" when exchanging information.

How does it work?

HTTP is a TCP/IP application layer protocol. That is something unintelligible for a beginner but here we go: the protocol works on top of the Client-Server model, which assumes that a Client (a computer, a cell phone, a smartwatch, etc) makes resource requests to a Server (well, I don't have a lot of analogies for that, but for now we’ll say it’s a computer that just stores files in general). When you access a website, you are making a request to a server for one or more files that make up the website you want to access; the server checks whether your request is valid or not and sends these files to you; so, you finally see the site on your screen. The page usually comes rendered in an HTML file (short for Hyper Text Markup Language).

Request Types

The first line of every request identifies its type. Requests can have some types. The main types are:

GET: Request to get data from the server, whether that data is a page, an image or the response to any behavior done by the Client;
HEAD: Similar to GET, but returns only the page header to the Client;
POST: This type of request can be understood as the opposite of GET. The Client sends data to the server, be it login data, image uploads or even a message on a service like Whatsapp, for instance;
PUT: Similar to POST, with the difference that it is used when the Client wants to send only a part of a record and not a new complete record, such as when you change your username on a social network. So that the Client does not need to send all your data again, overwriting your old registration, he sends a PUT with only the new name;
DELETE: Request to delete some record on the server.

Request Headers

Every request, therefore, has a type and that type is specified in its header. An example of a header would be:

GET / HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:76.0) Gecko/20100101 Firefox/76.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: pt-BR,pt;q=0.8,en-US;q=0.5,en;q=0.3
Connection: close
Cookie:

The first line of this header identifies the type (method) of the request. As we can see, it is a ** GET . Still on the first line, we can see which path is inside the Server (Host) where the request is being sent. In this case, the Client wants to access the root page, "/". The third and last data of the first line tells the server which version of the HTTP protocol is being used. In this case, **HTTP / 1.1.

The rest of the header content can vary, relatively. Its representation is always structured following an order of Name:Value.

The most common data sent in a header are:

Host: Domain name of the server, that is, the domain to which you are trying to send your request, such as www.facebook.com or www.google.com;
User-Agent: This piece of data is used to identify to the Server (Host) who is making the request, containing data such as the Client's browser, version and operating system;
Accept: Tells the Server (Host) what types of data the Client is able to understand. This is essential for the Server to be able to respond to the Client's request in a way that it understands. Examples of this data are text/plain e application/json;
Content-Type: This data is similar to the aforementioned Accept. The difference is that in this case, we are identifying what type of data is sent by the request. The text/plain and application/json examples also apply;
Connection: Defines whether or not the connection to the Server (Host) should be kept open for future requests. When the connection is maintained, keep-alive is sent; when not, close;
Cookie: Cookie assists in the processes of maintaining the user session and identifying the client. As HTTP is a stateless protocol, it cannot maintain a "state" of the Client. So, when you log in to a website and then want to perform some task that requires the user to be logged in, you would need to log in again. In order for this redundant process to be avoided for the Client, we use Cookies. It is nothing more, grossly, than a hashed string that can load user data, such as your login, password and complementary data to the aforementioned User-Agent;
Referer: This data provides to the Server (Host) the address from which the request is originated, which can be used for tracking and analyzing usage of a website, for instance;
Origin: This data is quite similar with Referer, but it takes a more simplified data about the origin of the request to the Server (Host). While Referer usually sends the entire path to a URL (such as www.example.com/home/login), Origin would send something like www.example.com.

Everything that goes up must come down

And it is no different with requests. Just as the Client needs to send his request, identifying himself and following the standards of Header, the Server (Host) needs to send a answer to this request, what we call Response.

An exemple of Response is:

HTTP/1.1 200 OK
Date: Tue, 02 Jun 2020 21:45:35 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=UTF-8
Strict-Transport-Security: max-age=31536000
Server: Apache/2.2.14
X-Frame-Options: SAMEORIGIN
Set-Cookie:
Connection: close
Content-Length: 194814

As we have already seen, this first line is very similar to the first line of the Header sent by the Client, with the difference that, in this case, the Client receives the HTTP version and the Response Status.

There are dozens of status codes and it is up to the developer to investigate which is more appropriate, if he is responsible for sending it from the server. For cases where the developer is on the Client's side, a quick search for the code number provides clarifying answers.

In any case, it is important that we have general knowledge about these codes so that we are not caught completely off guard when an unprecedented code appears. To facilitate memorization, we can generally classify the codes by their initial digit:

Started with 1 (101, 102, etc): Returns information about the request, whether it was accepted or whether the process continues;
Started with 2(201, 202, etc): Returns that the request was successfully executed, its types being referenced to the different types of requests that can be executed;
Started with 3(301, 302, etc): Returns the information that there is a need for redirection so that the execution of the request can be completed;
Started with 4(401, 402, etc): Returns the information that there is an error on the part of the Client in the request;
Started with 5(501, 502, etc): Returns the information that there is an error on the part of the Server(Host) in the request.

Other data returned in a Response are:

Date: Date on which the response was originated;
Expires: Information about when the content should be considered out of date. The value -1 indicates that the content expires immediately after being sent;
Cache-Control: Provides information about cache policies;
Server: Provides information about the server;
Set-Cookie: Provides Cookies sent from the server to the Client;
X-Frame-Options: Provides information for the browser to render (or not) a page in <frame> or <iframe>.

What about the body?

Of course, in addition to the headers, there is the body of requests and responses. It usually includes data related to the request that does not identify the Client/Server or does not have sensitive data that, if intercepted, can cause security problems.

HTTP x HTTPS

HTTPS (Hypertext Transfer Protocol Secure) is nothing more than a more secure version of HTTP. It is a junction of HTTP with the SSL (Secure Sockets Layer _) / TLS (_Transport Layer Security) protocol created to ensure the transmission of sensitive information such as personal data, payment and login data. SSL / TLS protocols allow data to be transmitted over an encrypted connection and require that the Server(Host) and the Client are authentic. HTTPS became primarily necessary due to the massive increase in the use of Wi-Fi connections, in which it becomes possible to carry out attacks by intercepting the data between the Client's exit and the entry in the Wi-Fi modem, for instance. Such attacks are known as Man in the Middle attacks.

Did you like the article? Do you think there was a missing question to be addressed?

Please comment and let me know if this content helped you in any way.

See you later, aligator!

Originally posted in Portuguese here