DEV Community: Jeferson 'Shin' Leite Borges

The Struggles of Making Games

Jeferson 'Shin' Leite Borges — Wed, 10 Jul 2024 19:47:07 +0000

Ok, I'll try to write this post in both portuguese and english.

English

When I started making games around 2018, it was just for fun. I was excited about my progress with JavaScript, and the idea of using some of that knowledge to make games felt like a natural leap.

But there's more to the story.

When I was 10, I made simple games with Game-Maker
(note that this is not GameMaker, it's Game-Maker, with a - in the middle; totally different products, like something Microsoft would name)

At 13, I toyed with RPG Maker 2000, which was super innovative at the time. Lots of events and many small RPGs that never went anywhere. I remember trying to make one, and the best I could do was create some half-baked enemies and a nonsensical story that went nowhere.

At 15, with a good friend from my youth (who I still miss), we messed around with PHP to create a little map for use while playing GURPS.

A few years later, while talking with a coworker, we had just finished playing Cave Story, which had received a fan translation. I discovered it was made by just one person. Soon, we were discussing, "Why don't we make a game?"

This was back in 2005, almost 10 years before Godot existed and about 5 years (if not more) before anyone had free access to Unity. But the world wasn’t hopeless, and Allegro was there to save the day.

By the way, that page looks the same as when I first saw it in 2005.

As I learned to write code in C, something I had never done before (the closest was a bit of BASIC, lots of Excel functions, and some Lisp for AutoCAD), but nothing was going to stop me from progressing.

After a few days, I had a sprite on the screen that I could move with the arrow keys, basically the hello world of any game dev!

Conversations came and went, and my coworker didn’t want to make the sprites for the game anymore. All I had left was a png file full of dreams.

In 2013, when I graduated in Industrial Design, I made a board game for my final project, one of many I created during my university years. Sadly, I shared very few with friends (something I should have done much more).

Before I knew it, it was 2018, and I was opening the newly released Godot 3. I started making little games again, and usually, the same thing breaks me: "Art."

How to make the "Art." I understand the process of "design," I can do it, and I can write code where I can understand myself well enough. But the "art." That I need to define.

What is "art"?

The first two things that come up in the dictionary are:

The ability or skill to apply knowledge or execute an idea.

A set of means by which something can be practically realized.

And what is "art" for me in the context of Game Dev?

Art is the process by which design material is converted into assets for a game.
In this case, graphics, music, code, dialogues, sound effects...

Alright, if art is everything that makes a game, a game.

So, what’s the problem?

The problem is that, even with effort, I still can’t reach a quality level that satisfies me. I can make music, sound effects (even if most are just blips and blops), and I can create the pixel art that I love.

But I don’t enjoy this process. Opening my text editor to write code is fun, opening the pixel editor and designing a character is cool... but...

Animating is a pain,

Pixel art is fun, but animating is a real drag.

Composing music is cool, but man, it takes me almost an entire day to compose one song, and it still feels subpar.

Sound effects never bothered me; just grab some objects around the house and record with the mic, throw in tons of effects, and it’s done.

I enjoy coding, and I usually can make way more than one mechanic a day for my tiny games.

So what to do? I have no idea

But let me tell you what hasn’t worked so far:

Writing a Game Design Document (GDD)

Of course, the process maniac here decided to put a process into making games. Many hours of planning have been done, and my list on itch remains the same.

For every item on itch, I must have at least 3 other GDDs that never left the paper. And for every game there, I have at least 5x more material in GDD to continue the game.

What doesn’t work?

Overplanning and not seeing results.

The more I prepare, the less perceptible the results are. It just feels farther from finishing. There are always more sprites to be made than I have lifetime to create, always more music to be composed than I have the capacity to make.

And remember, I’m a hobbyist at this, and my drawing and composing skills are limited. (To not call it mediocre)

Kanban, Trello, Jira...

No matter the type of board, it’s just a more visual way of doing a GDD, and simpler. The more information on each card, the worse; the less information on each card, the worse.

I tried putting cards with tags, colors, drawings, icons, but in the end, it’s just effort that I don’t see where it’s going, and that I could be using to write more code or make more graphics.

Between a board and a checklist, I prefer the list.

Simple text files or Markdown?

If it’s a checklist, why not go straight to text files?

Markdown is the new .doc for developers, but with fewer color effects for words and no way to link to a data sheet, but it works well enough, honestly.

It works as mind map. But when it starts getting heavier than that, it loses its point, especially if you want to include time estimates or try to create a pseudo-Trello. It doesn’t work. Don’t try it, you’ll get hurt!

Now, if it’s just "to-do lists" or a simplified version of GDD, it "works" within limits.

And the future?

So what now that I’ve compiled all the information? As I said here, I have no idea. But all mistakes lead you forward, helping you learn and become a better dev, or in this case, a better game dev, right?

I hope so.

That’s it for today, thank you.

(()=>{})()

Portugues

Quando eu comecei a fazer jogos em meados de 2018, era apenas uma brincadeira. Estava empolgado com meu desenvolvimento em JavaScript e pensar que poderia usar parte do conhecimento para fazer jogos foi apenas um salto natural.

Mas, existe algo que precede isso.

Quando tinha 10 anos, fazia jogos simples com Game-Maker
(repare que esse não é o GameMaker, é o Game-Maker, com um - que separa o nome; produtos totalmente diferentes, parece até a Microsoft dando nome a produtos)

Quando tinha 13 anos, brincava com RPG Maker 2000, que era super inovador na época. Vários eventos e muitos pequenos RPGs que nunca chegaram a lugar algum. Lembro de ter tentado fazer um e o melhor que consegui foi criar meia dúzia de inimigos e uma história sem pé nem cabeça que leva de lugar algum para lugar nenhum.

Quando eu tinha 15 anos, junto com um grande amigo de juventude (de quem sinto falta até hoje), fizemos uma brincadeira em PHP. Era apenas para ser um mapinha para usar enquanto jogávamos GURPS.

Alguns anos depois, enquanto conversava com um colega de trabalho, tínhamos acabado de jogar Cave Story, que havia recebido uma tradução de fã, e eu descobri que tinha sido feito por apenas uma pessoa. Logo entramos no assunto "por que não fazemos um jogo?".

Isso foi em 2005, quase 10 anos antes do Godot existir, e uns 5 anos (se não mais) antes de qualquer um ter acesso (gratuito) à Unity. Mas ainda assim o mundo não estava perdido, e Allegro estava aqui para te salvar.

Inclusive, essa página continua igual desde que eu a vi pela primeira vez em 2005.

Enquanto eu aprendia a escrever código em C, algo que nunca fizera antes, o mais perto que cheguei foi um pouco de BASIC e muitas funções de Excel, além de um pouco de Lisp para AutoCAD, mas isso não iria me impedir de progredir.

Depois de uns dias, eu já tinha um sprite na tela e conseguia movê-lo com as setas do teclado, basicamente o hello world de qualquer game dev!

Conversas vão e vêm, e meu colega de trabalho não queria mais fazer os sprites para o jogo, e a única coisa que me restou foi um arquivo png com sonhos ali.

Em 2013, quando me graduei em Design Industrial, fiz como projeto de graduação um jogo de tabuleiro, um de muitos que fiz ao longo dos anos na universidade, e tão poucos compartilhei com amigos (algo que deveria ter feito muito mais).

Quando me dei conta, era 2018 e eu estava abrindo o recém-lançado Godot 3, e então comecei novamente a fazer joguinhos. Geralmente o ponto que me quebra é o mesmo: "Arte".

Como fazer a "Arte"? O processo de "design" eu entendo, sou capaz de fazer, escrever código onde consigo me entender o bastante; mas a "arte", essa eu preciso definir.

O que é "arte"?

As duas primeiras coisas que aparecem no dicionário são:

Capacidade ou habilidade para a aplicação de conhecimento ou para a execução de uma ideia.

Conjunto dos meios pelos quais é possível obter a realização prática de algo.

E o que é "arte" para mim no contexto de Game Dev?

Arte é o processo pelo qual o material de design é convertido em assets para um jogo.
Nesse caso gráficos, música, código, diálogos, efeitos sonoros...

Certo, então arte é tudo o que faz um jogo, jogo.

E onde está o problema?

O problema é que eu, mesmo com esforço, ainda não consigo atingir um ponto de qualidade que me deixe satisfeito. Sou capaz de fazer músicas, efeitos sonoros (mesmo que a maioria sejam blips e blops), e consigo fazer a pixel art que tanto gosto.

Mas eu não me divirto nesse processo. O processo de abrir o meu editor de texto e escrever código é divertido, abrir o editor de pixel e fazer o design de um personagem é legal... mas...

Fazer animações é um saco,

Pixel art é legal, mas fazer animações é um belo pé no saco.

Compor música é legal, mas pai amado, eu levo quase um dia inteiro para compor uma música, e ainda assim fica meia boca.

Efeitos sonoros nunca me incomodaram, basta pegar uns objetos pela casa e gravar com o microfone, jogar toneladas de efeitos e está pronto.

Código eu me divirto, e geralmente consigo fazer muito mais do que uma mecânica por dia para meus jogos minúsculos.

E então o que fazer? Eu não tenho ideia

Mas deixa eu te falar o que não funcionou até agora:

Escrever um Game Design Document (GDD)

Claro que o maluco dos processos aqui iria decidir colocar processo para fazer os joguinhos, e muitas horas de planejamento já foram feitas e minha lista no itch continua no mesmo.

Para cada item no itch, eu devo ter pelo menos 3 outros GDDs que nunca saíram do papel. E para cada jogo ali, eu tenho pelo menos mais 5x mais material em GDD para continuar o jogo.

O que não funciona?

Planejar demais e não ver resultado.

Quanto mais eu preparo, menos resultados são perceptíveis, apenas que está longe demais de terminar. Sempre tem mais sprites para serem feitos do que eu tenho tempo de vida para fazer, sempre tem mais músicas para serem compostas do que eu tenho capacidade de fazer.

E lembre-se, eu sou um hobista nisso, e minha capacidade de desenho e composição são limitadas. (Para não chamar de meia-boca)

Kanban, Trello, Jira...

Não importa o tipo de board, isso é apenas uma forma mais visual de um GDD, e mais simplista. Quanto mais informações em cada cartão, pior; quanto menos informação em cada cartão, pior.

Tentei colocar cartões com tags, coloridos, com desenhos, com ícones, mas no fundo, isso é apenas esforço que não vejo onde está indo, e que poderia estar usando para fazer mais código, ou fazer mais gráficos.

Entre um board e uma lista com check-list, prefiro a lista.

Arquivos de texto simples, ou Markdown?

Se é check-list, por que não ir direto aos arquivos de texto?

Markdown é o novo .doc do desenvolvedor, mas com menos efeitos de cores para as palavras e não tem como conectar numa planilha de dados, mas funciona bem o bastante, sinceramente.

Funciona como organização de pensamentos. Mas quando começa a ficar mais pesado que isso, perde o sentido, principalmente se quiser colocar estimativas de tempo, ou tentar fazer um pseudo-Trello. Não funciona. Não tente, você vai se machucar!

Agora, se for apenas "listas do que fazer", ou uma versão simplificada de GDD, "funciona" dentro dos limites.

E o futuro?

E o que fazer agora que compilei todas as informações, como eu disse aqui, não tenho ideia. Mas todos os erros te levam para frente, te fazem aprender a se tornar um dev, ou nesse caso um game dev, melhor, não?

Espero que sim.

Isso é por hoje, obrigado.

(()=>{})()

Today I uninstalled VSCode

Jeferson 'Shin' Leite Borges — Fri, 01 Mar 2024 10:08:51 +0000

TL:DR

Yup, this is real, this is totally legit.
On this very day I finally uninstalled VSCode.
Goodbye Microsoft, and fˆ%c off!

Let me start with some context, I didn't start as a software engineer, but I was there:

When bgcolor was an official property of HTML for styling
When jQuery was something useful with WordPress
When actionScript was the future of the internet

My first hello world was on the DOS with a little BASIC magic, but at the time this was not "software", just scripts, and I always used these "scripts" for simple stuff, automating my routine with design tools, and making my life easier, little did I know that these scripts were already "software", just my mind didn't recognise as software.

I was naive.

In the last decade, when I started to code for real, I needed a tool for this, and Google Docs wouldn't help that much

But which text editor can I use? At the time there was not a single good solution, I saw some people with fancy IDEs, but this looks too complicated for my two-neuron-brain.

So there was the simple Sublime, which was good for the first few years, then I found Brackets a text editor for the web, at the time software it was from the beloved Adobe, so it was a nice choice.

I can design in Photoshop, open the Brackets and apply the changes there. Perfect match!

A few years later I had to jump on Atom, and another year I was on the VSCode which was my home for the last 6 years.

Everyone in the team uses it, friends, managers, the "namaste" guy, that nerdy Trekker, my uncle after downloading a "legal" version of Minecraft, your mon...

But I know better, I know Microsoft, I saw what you did in the past, and I know how scummy and degenerated you are. That's why I never fully trusted.

At some point, I'll need to move.

But move to where? Zed isn't an open source (at the time), Atom is pretty much dead, maybe put my coins in the Lapce, it's made with Rust, so should be blazing fast.

But they all felt that something was missing, there was no magic, there was no mystery.

The more I looked, the less I felt like changing from VSCode, and more frustrated with the conditioning that Microsoft did on my brain to not even try something else.

One day I saw my coworker using a very strange code editor, in the terminal, and I do spend a fair amount of time in the terminal, so why not?

I decided to test, and I failed super hard. How am I supposed to use this tool? Why do I need to use hjkl to move the cursor? What curse is that?!

I quickly moved back to the safe walls of VSCode, but this little interaction made me think. Looks like this could be the new mystery for my two-neuron-brain to solve. But making the change would be too much effort, so how to make this change in a slow and easier manner?

First I need to learn the Vim motion, this is the way that this text editor moves things, and soon I found that pretty much all code editors have a way to enable this feature, from the elite JetBrain shitware to the worse nightmare xCode.

So I just need to enable this feature on the VSCode, and... F&ˆK.

There is no toggle for that, where in my settings.json do I need to add to enable this? What do you mean there is an extension for that? Fine, one download later and I can start using it.

The first step was the hardest one, but now I can feel comfortable.

One day I did open my VSCode and I saw the new update, and I sniffed the usual shitification, looks like Microsoft is now collecting more data from me, more data from my usage, but wait. I did disable the telemetry, and I saw my json file with this flag disabled, but why I can see the network call for the Microsoft server?

Considering my familiarity with the amazing quality of Microsoft, and looks like when you disable the telemetry, you disable part of it, not all of the telemetry, for the "bugs", "crash", and training data for the "Copilot", this is never an option.

For some reason I'm not surprised.

If you look at the Edge Browser, it had a good start, but now just look at it and you can see the shitfication, Windows were never good to start, and the Teams was so badly bad that had to start from scratch to be just "bad" again.

And I ask, why VSCode would be different?

Time to say goodbye to bloatware about AI shit forced on the developers on a global level trying to squeeze a few extra copilot subscriptions.

And with this, I'm moving my things to NeoVim and on the terminal I'll stay. Until Microsoft buys this software and turns it into shit.

Thanks for reading,
And special thanks to this coworker who showed me the way,
And another one to the cult leader ThePrimeagen

Ps.: If you got offended by any text about Microsoft, I can recommend this article to help.

Web Security

Jeferson 'Shin' Leite Borges — Tue, 07 Feb 2023 12:23:58 +0000

What are these texts?
I was studing and for me to have some real study done I need to write it down, this is a small collection of topics that I studied in the last few weeks.
Other links from the same study-pool:

Branching Strategies > > - CI / CD

Critical Rendering Path

Requirements

Release Strategy

REST

Static Analysis

Web Security

Web Security

Web apps have become essential business enablers as more organizations use them for a variety of purposes, including e-commerce, customer engagement, and employee empowerment. These apps continue to be the target of serious cyber attacks despite the fact that they generate enormous amounts of user and organizational data. Web security fundamentals, common vulnerabilities, and resources to keep up with the shifting threat landscape are covered in this article.

Online Web Applications Security Project (OWASP)

The Open Web Application Security Project, or OWASP, is an international non-profit organization dedicated to web application security. One of OWASP’s core principles is that all of their materials be freely available and easily accessible on their website, making it possible for anyone to improve their own web application security. The materials they offer include documentation, tools, videos, and forums. Perhaps their best-known project is the OWASP Top 10.

Top ten list

Injection.
Before understanding user input, web apps that take it must correctly validate it. Attackers may inject code or commands that are then executed if this is not done correctly. A successful injection can lead to a number of detrimental effects, ranging from attackers gaining access to sensitive information to losing administrative control of the server.
Broken Authentication.
Many web applications depend on authentication and session management. Attackers may be able to steal user identities and accounts thanks to security weaknesses in these procedures.
Sensitive Data Exposure.
To keep it from being accessed by outside parties, web applications must secure the data they process, both while it is in transit and while it is at rest. This is crucial for PII that relates to financial data, healthcare data, and other types of PII (Personally Identifiable Information). Credit card fraud, identity theft, account takeover, and other attacks are included in the risk category of sensitive data exposure.
XML External Entities (XXE).
A common format for storing and sharing data is XML and JSON. It features the capability to dereference local or external URIs using the parser. An attacker may use a poorly-configured parser in a number of different ways. Malicious XML/JSON can attempt remote code execution, refer to confidential local data (such a file containing user credentials), or conduct a DoS (Denial of Service) assault by accessing local resources, among other things.
Broken Access Control.
This refers to inadequately-enforced restrictions on what authenticated users are allowed to do. A system with this flaw can allow attackers to gain unauthorized access to data, and even to interfere with the access that legitimate users have.
Security Misconfiguration.
This group of dangers is highly diverse. It covers a wide range of topics, such as unpatched vulnerabilities in services, libraries, frameworks, and applications, incorrectly configured HTTP headers, sensitive information contained in verbose error messages that can be used to strengthen an attack, and open cloud storage (data stored in the cloud with unrestricted access privileges).
Cross-Site Scripting (XSS).
Numerous online apps include user inputs into their sites. In XSS, an attacker provides inputs that contain scripts, the attacker wants the scripts to be included in the pages delivered to other users. (Common examples include comments, product reviews, user profiles for membership sites, etc.) An attacker can do a number of things if a web application does not correctly validate its inputs, including hijacking user sessions, changing the pages that are served to other users, and rerouting other users to malicious websites.
Insecure Deserialization.
XML and JSON are often used to serialize data. Web applications are vulnerable to malware payloads if they receive serialized data from unreliable sources. Numerous exploits, such as privilege escalation and remote code execution, may emerge from this.
Using Components with Known Vulnerabilities.
If a library or framework that an application utilizes has a known exploit, the attacker may be able to access the same internal resources as the program if they are successful. Depending on the application's access, this might lead to anything from server espionage and remote code execution to data theft.
Insufficient Logging & Monitoring.
Web applications must accurately record events so that administrators may determine if potentially malicious activity is taking place. Organizational regulations should also mandate that administrators keep a close eye on the logs to see what's happening. Failure to do so will significantly increase the harm done by successful attacks and frequently enable attackers to switch targets and broaden the scope of their operations. This risk might appear the simplest to manage out of the top 10, yet it still poses a serious threat to business.

Some Specifics

OWASP is a gives the general idea on how to manage and work with the security for web applications. Still there is some common know vector for attacks.

SQL Injection

An attacker can take advantage of weaknesses in a database's search process by using SQL injection. SQL injection allows an attacker to get access to sensitive data, create or modify user rights, or carry out data change, manipulation, or destruction schemes. A hacker can thus seize important data or change it to prevent or manage the operation of a vital system. An easy way to accomplish this though non-validate user input, or query params.

Cross-site Scripting

Cross-site scripting (XSS) is the name of a flaw that allows attackers to place client-side scripts inside of a page. This is then utilized to have immediate access to crucial info. A hacker may employ XSS to impersonate another user or trick a user into exposing important information. Some examples could be unintentional ability for the user to add custom details on their profile non-validating this user input.

Remote File Inclusion

With remote file inclusion, an attacker makes use of flaws in a web application to reference external scripts. The attacker can then try to upload malware using an application's referencing feature. These malware varieties are also known as backdoor shells. The entire process is carried out from a different Uniform Resource Locator (URL) on a different domain.

Password Breach

Password hacking is a frequent method used to access online resources. Frequently, a hacker will use a password that a user or administrator had previously used to sign in to a different website for which the hacker has a list of login information.

In other instances, hackers employ a method known as "password spraying," in which they utilize well-known passwords like "12345678" or "password123" and attempt each one individually until they succeed in gaining access. Other methods include employing keyloggers or just looking for your password on paper and utilizing it.

Data Breach

An information breach occurs when private or delicate data is made public. Data breaches can occasionally occur by mistake, but they are frequently the work of hackers who want to use or sell the data.

Malware Installation

Malware can do a great deal of harm once it has been installed on a local network, including data exfiltration, ransomware encryption, and extortion.

Phishing

Since the majority of attacks begin with phishing emails, online security must have a method to prevent fraudulent emails from getting to an employee's inbox.

Distributed denial-of-service (DDoS)

The distributed denial-of-service (DDoS) assault allows attackers to disrupt services for days at a time, harming revenue and operational continuity.

Tool of trade when dealing with web security

These are some ways to protect the web application against some attack vectors.

Web Application Firewall (WAF)

A good WAF can potentially reduce or stop DDoS attacks and reduce or block malicious code injection when users submit information using online forms. It can substantially boost your techniques and reduce attacks, but it shouldn't be the only way to counter web-based attacks.

Vulnerability scanners

Before it is put into use, any software should be penetration tested, but even in production, it should be regularly checked for security flaws. Scanners carry out simple hacker behaviors to discover weaknesses in your software. You can address problems before they lead to a serious data breach if you identify vulnerabilities before attackers do. Good scanning tools also look for corporate infrastructure configuration errors.

Fuzzing tools

Similar to scanners, fuzzing tools can evaluate code as it is being produced in real time. A fuzzer checks the code before it is deployed to staging, throughout testing, and lastly before it is deployed to production. A fuzzer, as opposed to a straightforward scanner, offers information on the potential issue to assist developers and operational staff in resolving it.

Black box testing tools

Black box testing techniques simulate real-world attacks to detect flaws in software, which attackers utilize in a variety of ways. These tools carry out harmful operations against installed software to find potential security holes and make use of widely available exploits to assist developers in fixing problems.

White box testing tools

Coding errors cause widespread vulnerabilities to be introduced as developers create their programs. A white box testing tool evaluates code as it is written and gives developers knowledge to assist them avoid frequent errors. Consider white box testing as a means to monitor the creation of software in order to identify vulnerabilities before the code is compiled and released to testing and production settings.

Static Analysis

Jeferson 'Shin' Leite Borges — Tue, 07 Feb 2023 12:23:54 +0000

What are these texts?
I was studing and for me to have some real study done I need to write it down, this is a small collection of topics that I studied in the last few weeks.
Other links from the same study-pool:

Branching Strategies > > - CI / CD

Critical Rendering Path

Requirements

Release Strategy

REST

Static Analysis

Web Security

What are "static analysis" tools?

Static analysis tools refer to various tools that examine source code, executables, and even documentation to find problems before they occur. No code is actually executed.

These tools vary widely in scope and purpose, from compiler-level logic error checking and code style enforcement to cloud-based tool suites that cover everything from formatting documentation to analyzing code complexity.

In short, you can think of a static analysis tool as any tool that helps you maintain a healthy codebase without actually running that code.

Why are they useful to you?

Ultimately, we want successful features/tools/products/etc. Build and deliver. It takes effort, time and money.

In the short term, we can choose to accept technical debt, smelly code, and bad practices.

Ultimately, however, all of these things catch up to us. Technical debt, smelly code, and emerging bugs slow down development cycles, reduce product quality, and ultimately increase the effort, time, and money required to develop a product.

Static analysis tools can help us find and fix these issues more easily before they have a significant impact on our projects, reducing and preventing these issues across the board.

Code Quality

You can enforce coding standards and analyze dependency graphs.

You can analyze control flow, nesting, and data flow, as well as the complexity of blocks, functions, classes, files, and more.

There are tools to analyze requirements documents or code documents.

They can be used to reformat code or measure test coverage.

These things tend to look small in isolation, but if ignored, the quality of our code can slowly degrade over time.

With the right tools, we can analyze and optimize our code more easily. This makes the process more efficient and therefore more likely to last over the life of our project.

If our code was evaluated the same way by a tool every time, our team might also learn to write code with fewer problems.

Static analysis tools can improve the initial quality of our code, which can reduce the number of issues the tool needs to detect. Through this iterative process, the codebase can be further refined.

In a perfect world, we would start by writing problem-free code. Of course, we don't live in a perfect world and bug-free code is a dream, but if we continually analyze our code, fix those problems, and learn from the process, we can continue to write more efficient code.

Code Review

The simple answer is that you don't.

A big part of growing up as a software engineer is learning to analyze our code and introduce many of the ideas mentioned above. While reviewing code we can skip any type of tools and apply code analysis.

But building software is much more than just code and yet we only have so much time in the day and so much brain power to spare. Finding and implementing all these different code quality components slows down the code review process considerably and makes it a burden rather than a great learning opportunity.

Incorporating static analytics into the development and/or build pipeline automatically relieves the burden of manually performing analytics. There is no need to apply code patterns by manually commenting out each PR line. Code complexity analysis can be time-consuming and difficult for a developer.

This tool can perform the same analysis every day with the same attention to detail. Relying on static analysis tools also removes the human element from potentially frustrating parts of the review process such as careful design or convention errors.

The tool suggests deviations from an agreed-upon style without the need for back-and-forth between team members. There is no bias. The machine is not in a bad mood and hangs on every little thing.

Either the device succeeds or fails. Less time spent discussing and debating minor points in the review leaves more time for more interesting and important conversations. What tools do well cant happen if its entirely the developers responsibility.

Secure your code reviews and automate as much as possible.

Tools to use:

These are some common use tools for the most commons scenarios on the Javascript and front-end development.

ESLint

ESLint is an open source Javascript tool by Zakas in June 2013. Often used to find problematic patterns or code that doesn't follow certain style guidelines. ESLint is written using Node.js to provide a fast runtime environment and easy installation via npm. With ESLint you can enforce coding standards using a fixed set of independent rules. Yes you can enable and disable the rule. These rules are fully binding.

Why use ESLint?

JavaScript is a dynamic language that is loosely typed and very prone to developer error. ESLint helps you incorporate guidelines into your coding standards and helps reduce these errors. The main reason for implementing such a guide is that each developer has their own writing style (naming conventions/tabs/single or double quotes for strings etc.). Additionally different styling techniques can make your codebase look different more error prone and more fragile. This can lead to pitfalls that you don't want to face especially when dealing with JavaScript.

When to use it?

This is the type of tool that can be used regardless of project size or team. In both cases you should apply the usual standard coding practices/guidelines. Linting tools like ESLint allow developers to find problems without running their own JavaScript code. One of the main reasons for creating ESLint was to allow developers to create their own lining rules.

How to use it?

You can install ESLint using npm or yarn:

npm install eslint --save-dev ## or yarn

Note: It is also possible to install ESLint globally rather than locally (using npm install eslint --global). However, this is NOT recommended, and any plugins or shareable configs that you use must be installed locally in either case.

After installing it, initialize it with the following command:

npx eslint --init

Note: — init assumes you have a package.json file already. If you don't, make sure to run npm init or yarn init beforehand.

The moment you're done with the installation and initialization you'll have a .eslintrc.{js,yml,json} file in your directory. In it, you'll see some rules configured like this:

// eslint.rc
{
  "rules": {
    "semi": ["error", "always"],
    "quotes": ["error", "double"]
  }
}

If you're here that means you've successfully configured the ESLint. Here's how you can use it:

npx eslint <your file>.js
## or
npx eslint <folder containing js files>

You can also add lint in your package.json file (if not already added)

"scripts": {
  ...
  "lint": "eslint .",
  ...
}

Prettier

Prettier applies a consistent code style to your code base (ie code patterns that don't affect the AST). This is because it ignores the original style and recasts the parsed AST to its own rules that use maximum lines. Consider the length and wrap the cords when necessary.

Why prettier?

The biggest reason for adopting Prettier is to stop all the ongoing debate about style. Its generally agreed that a general style guide is valuable for a project or team but getting there can be a painful and rewarding process. People are very passionate about how to write specific code and no one likes to spend time writing or getting information.

Prettier is generally recommended for those with existing codebases and JavaScript experience but those who benefit disproportionately are those new to codebases. People might think this is only useful for people with very limited programming experience but we've seen experienced engineers shorten the onboarding time to join the company because they've coded before. Different styles can be used and developers can come. in other programming languages.

What usually happens after using Prettier is that they realize that they actually spent a lot of time and mental energy designing their code. With good editor integration you can hit that magic link key and the code is formatted. It was an eye-opening experience if ever.

How to use it?

Prerequisites: Node.js (^10.12.0, or >=12.0.0)
You can install ESLint using npm or yarn:

npm install prettier --save-dev ## or yarn
touch .prettierrc ## Create the basic configuration file

In the configuration file you can extra configure for your taste of for the project needs.

// .prettierrc
{
  "trailingComma": "es5",
  "tabWidth": 4,
  "semi": false,
  "singleQuote": true
}

You can run the prettier and format the files with

npx prettier --write .

You can also add lint in your package.json file (if not already added)

"scripts": {
  ...
  "lint": "prettier --write .",
  ...
}

SonarQube

From all the options, this is the heavier one.

SonarQube is an open source platform developed by SonarSource for continuous code quality checking. Sonar performs static code analysis and provides detailed reports on code duplication code smells errors and vulnerabilities.

Benefits of SonarQube

Sustainability - Reduce complexity and improve application life by duplicating code for potential vulnerabilities.
Productivity - Reduce maintenance costs and operational risk at scale. This eliminates the need to modify the code.
Quality - Code quality control is an integral part of the software development process.
Errors - It detects code errors and prompts developers to automatically fix them before sending output.
Consistency - Determines where code standards are violated and improves quality.

Developers provide functionality that developers need on tight deadlines. It is important for developers to compile quality code multiple times due to potential code duplication errors and deployment complexity.

How to use it?

Pre-requisites: Docker and Docker-compose

Create a docker compose file, add the follow content:

## docker-compose.yml
## https://github.com/SonarSource/docker-sonarqube/blob/master/example-compose-files/sq-with-postgres/docker-compose.yml
version: "3"
services:
  sonarqube:
    image: sonarqube:community
    hostname: sonarqube
    container_name: sonarqube
    depends_on:
      - db
    environment:
      SONAR_JDBC_URL: jdbc:postgresql://db:5432/sonar
      SONAR_JDBC_USERNAME: sonar
      SONAR_JDBC_PASSWORD: sonar
    volumes:
      - sonarqube_data:/opt/sonarqube/data
      - sonarqube_extensions:/opt/sonarqube/extensions
      - sonarqube_logs:/opt/sonarqube/logs
    ports:
      - "9000:9000"
  db:
    image: postgres:12
    hostname: postgresql
    container_name: postgresql
    environment:
      POSTGRES_USER: sonar
      POSTGRES_PASSWORD: sonar
      POSTGRES_DB: sonar
    volumes:
      - postgresql:/var/lib/postgresql
      - postgresql_data:/var/lib/postgresql/data

volumes:
  sonarqube_data:
  sonarqube_extensions:
  sonarqube_logs:
  postgresql:
  postgresql_data:

after the file created you just need a simple docker-compose up on the folder with the file to start the sonarqube.

REST

Jeferson 'Shin' Leite Borges — Tue, 07 Feb 2023 12:23:50 +0000

What are these texts?
I was studing and for me to have some real study done I need to write it down, this is a small collection of topics that I studied in the last few weeks.
Other links from the same study-pool:

Branching Strategies > > - CI / CD

Critical Rendering Path

Requirements

Release Strategy

REST

Static Analysis

Web Security

What is RESTful API?

To have a safe online information exchange between two computer it's needed an interface, one of then is RESTful API. To carry out various duties, the majority of business apps must interface with other internal and external applications. For instance, in order to automate invoicing and connect with an internal services application. This information exchange is supported by RESTful APIs because they adhere to safe, dependable, and effective standards for software communication.

What is an API?

An application programming interface (API) defines the rules that you must follow to communicate with other software systems. Developers expose or create APIs so that other applications can communicate with their applications programmatically. Usually there is an client and a resource that the client aim to retrive.

Clients: that seek to access information via the web are referred to as clients. The client, who makes use of the API, might be a person or a piece of software.

Resources: are the details that various programs give their users. Resources can be any kind of data, including text, numbers, photos, videos, and so on. The device that provides the client with the resource is also referred to as the server. While retaining security, control, and authentication, businesses use APIs to share resources and offer web services. They can also choose which customers have access to particular internal resources with the aid of APIs.

What is REST or RESTFul?

A software architecture called Representational State Transfer (REST) places restrictions on how an API should operate. REST APIs are APIs that adhere to the REST architectural design. RESTful web services are online services that use the REST architecture. RESTful web APIs are commonly referred to as RESTful APIs. REST API and RESTful API can, however, be used interchangeably.

What are the benefits of RESTful APIs?

Scalability

Because REST optimizes client-server interactions, systems that employ REST APIs can grow effectively. Because the server does not need to keep track of previous client requests, statelessness reduces server burden. Some client-server interactions are reduced or eliminated entirely by properly managed caching. All of these aspects enable scaling without creating performance-degrading communication bottlenecks.

Flexibility

Total client-server separation is supported by RESTful web services. In order for each server component to develop independently, they disconnect and simplify the numerous server components. Changes to the server application's platform or technology have no impact on the client application. Flexibility is further increased by the option to overlay application features. For instance, developers don't need to rewrite the application logic to make changes to the database layer.

Independence

Regardless of the technology being used, REST APIs work. Different programming languages can be used to create client and server apps without changing how the API is designed. On either side, the underlying technology can be changed without impacting communication.

How do RESTful APIs work?

A RESTful API performs the same fundamental task as accessing the internet. When a client needs a resource, it uses the API to communicate with the server. In the server application API documentation, API developers outline how the client should utilize the REST API. The standard procedures for any REST API call are as follows:

A request is made to the server by the client.
- The client formats the request in accordance with the API documentation so that the server can interpret it.
The server verifies the client's identity and validates that the client is authorized to submit that request.
- The request is received by the server, which then handles it internally.
The client receives a response from the server.
- If the request was successful or not is indicated in the response to the client.
- Any information that the client asked for is also included in the response.
- Depending on how the API is designed by the developers, the REST API request and response details differ widely.

Details of the REST request

Unique resource identifier (URL)

The server identifies each resource with unique resource identifiers. For REST services, the server typically performs resource identification by using a Uniform Resource Locator (URL). The URL specifies the path to the resource. A URL is similar to the website address that you enter into your browser to visit any webpage. The URL is also called the request endpoint and clearly specifies to the server what the client requires.

Method (or Verbs)

Each resource is assigned a special resource identifier by the server. The server commonly uses a URL to identify resources for REST services. The path to the resource is specified by the URL. The website address you type into your browser to access any webpage is similar to a URL. The URL makes explicit to the server what the client needs and is also known as the request endpoint.

GET: used to access server-side resources at the URL provided. The server can cache GET requests and include arguments in RESTful API queries.
POST: used to deliver information to servers. Multiple requests for the same resource result in multiple copies of that resource being created as a byproduct.
PUT: used to complete update already-existing resources. The same request will not create multiple instances of the resource.
PATCH: used to modify already-existing resources. In contrast with the PUT, this request changes partial of the resource.
DELETE: used delete a resource. Usually this returns an empty body.

Headers

Additionally, the request includes headers or other metadata. They provide details like the server, encoding, timestamp, and content type and provide further context for the request. Commonly authentication is added as headers.

Message body

The resource representation is contained in the request body. Based on the information in the request headers, the server chooses an appropriate representation format. Clients may request data in the Text, XML or JSON formats for example.

Common authentication for REST

Basic authentication: The user name and password are sent by the client in the request header. Base64 is an encoding method that turns the pair into a collection of 64 characters for secure transmission.
Bearer authentication: The act of granting access control to the token bearer is referred to as bearer authentication. The server normally generates the bearer token in response to a login request. It is typically an encrypted string of characters. To access resources, the client includes the token in the request headers.
API keys: Another option for REST API authentication is API keys. In this method, the server gives a brand-new client a special created value. The client uses the special API key to identify itself each time it wants to access resources. Because the client must send the key, which leaves it open to network theft, API keys are less secure.
OAuth: For extremely secure login access to any system, OAuth combines passwords and tokens. The authorization process is completed by the server after it first requests a password and an extra token. It has a defined scope and longevity and can check the token at any time as well as over time.

How to read a REST response?

Status line

The three-digit status code in the status line indicates whether the request was successful or unsuccessful. The first character determines the type of the response, the other digits determine specific type of response.

1XX: informational
2XX: successful
3XX: redirection
4XX: client error
5XX: server error

Message body

The resource representation is contained in the response body. Based on the information in the request headers, the server chooses an appropriate representation format. Clients may request data in the Text, XML or JSON formats for example.

Headers

Additionally, the response includes headers or other metadata. They provide details like the server, encoding, timestamp, and content type and provide further context for the response.

Release Strategy

Jeferson 'Shin' Leite Borges — Tue, 07 Feb 2023 12:23:46 +0000

What are these texts?
I was studing and for me to have some real study done I need to write it down, this is a small collection of topics that I studied in the last few weeks.
Other links from the same study-pool:

Branching Strategies > > - CI / CD

Critical Rendering Path

Requirements

Release Strategy

REST

Static Analysis

Web Security

What is a release strategy?

Release is when the software is ready to be pushed to production. The process can also involves making the software open to a small group of users.

What kind of releases we can use?

Continuous release availability

Delivery teams can release their solutions whenever they want. This is the only strategy that supports continuous delivery. To make it work, a host of practices are required, such as fully automated deployment, fully automated regression testing, feature toggles, self-recovering components, and many others.

Release windows

A release window is a period of time when one or more teams can release into production. A release slot is a subset of the release window during which a team can deploy their solution into production. If your organization has a policy that production releases occur between 1 am and 5 am on Saturday nights, then up to four releases may occur during that window.

The advantages of this approach are that it provides a consistent release schedule to business stakeholders and that it has release date targets for delivery teams. Slow cadence release windows can be a problem for release management processes that need to support multiple teams. Teams have to aim for a future release window because there are only so many release slots available during each window. This problem gets worse when teams move to a continuous delivery strategy.

Release train

The idea of a release train is that every team involved with that train has the same release schedule, for example, this train releases once a quarter, or once a month, or even once a week. In large programs, where the individual teams are each working on part of a larger whole, this strategy is used.

A release train provides a consistent release schedule for stakeholders and serves as a rallying point for development teams. The train metaphor works well in practice. If your team misses the release date, the train goes on without you, and you need to wait for space on the next train.

Dependencies are also respected. Similar to a family taking a trip together, if several components need to ship together they have to go on the same train. Development teams are constrained to a common release schedule, making it difficult to support lean or continuous delivery strategies. Slow cadence release windows can cause a potential disadvantage, as release trains may also suffer from them.

Ring deployment

Different groups receive a new feature to manage the risk of deployment. These groups are represented as a series of rings, starting with a small group and growing to encompass all your users.

Pick users for each group based on similar attributes or an opt-in process if you do a ring deployment. Features can be made available to those groups. It is possible to release to internal users first, then to the other users, and then to all users.

Percentage-based releases

In a percentage roll out, the deployment has already happened and the release will be based on a percentage. The new feature will be rolled out to 10% of users, 25%, then 50%, until all users receive it. Users are randomly selected to get the new feature. If there is a way to identify them, they retain access to the new feature. When users must log in to use your product or accept cookies, this is the best kind of sorting.

There is little variation in your targeted user base, so these releases are useful when you cannot run a beta program. If you run a small B2B application with the same 1000 monthly active users, a percentage-based release is likely to give you an accurate estimate of whether the full rollout is likely to have a positive or negative impact on your user base.

Canary releases

A canary release is a test to see if a feature release will have a positive impact on users. Only a small number of your users will be able to use the new feature, and you can only target them based on who they are.

Make sure the small group in your canary release is representative of your overall users. Older versions of a phone's operating system may be missed if a canary release only goes to people with the latest phones.

A canary release can be used to test capacity management and user acceptance. If you roll out a new feature to a group and realize that it consumes too many resources, you can turn the feature off and make the product better.

Targeted releases

It makes sense to target a release based on something other than percentages. A food delivery service could try out a new feature or set of related features in one medium-size city to see how it works for multiple types of users.

If that service makes a change that affects restaurants, drivers, and consumers, all of those users should receive the change at the same time. If the city-wide roll out produces good results, the service can release it to the rest of their user base.

Entitlement releases

It's possible that you want a flag that affects access. What users can do on your platform is affected by these flags. An entitlement release can be used to add a feature that is only for a small group of users. If you had a premium service, you could change the release to only allow people who paid a membership fee to use it.

You can combine entitlement releases with percentage-based releases or canary releases, but only some users will have access to the feature after the release is done.

Post-release tasks

When the feature is fully deployed, your flag's lifecycle doesn't finish. You need to have metrics and monitoring set up to view human and system behaviors, and you need to have a plan to remove temporary flags after you fully implement the new feature.

Tracking metrics.

We can determine whether something is improving or not by using metrics. When releasing new features, you should consider what metrics you need to track.

With the deployment of a new feature, the availability, reliability, and response time of the application should not change. Before, during, and after you deploy code, set up monitoring to make sure it doesn't degrade.

Depending on your objectives and business, the metrics you track will be different. Tracking metrics such as page load time, errors, uptime, conversions, or user registration can tell you whether a feature is performing well or causing problems.

The flags are being removed.

It is not a good idea to include deployment and release flags in your code. After a feature is stable and fully released, you can remove the code associated with the feature flags. It eliminates the chance of accidental deactivation of the feature and makes your code easier to read and understand.

Requirements

Jeferson 'Shin' Leite Borges — Tue, 07 Feb 2023 12:23:43 +0000

What are these texts?
I was studing and for me to have some real study done I need to write it down, this is a small collection of topics that I studied in the last few weeks.
Other links from the same study-pool:

Branching Strategies > > - CI / CD

Critical Rendering Path

Requirements

Release Strategy

REST

Static Analysis

Web Security

What are requirements?

What you are going to accomplish is defined by the requirements. What will be included, what won't be included, how it will be done, and who will do it. Possible risks to the project, as well as criteria to measure the project's success, are often included in requirements. This information for the reader may include charts, graphs, diagrams, use cases, and mock-ups. It is necessary to define a project's need as well as the solution in order to write effective requirements. To write effective requirements, it must define a project's need as well as the solution.

What are functional requirements?

In software development, functional requirements determine the functions an entire application or just one of its components should perform. A function consists of three steps: data input – system behavior – data output. It can calculate, manipulate data, carry out business processes, establish user interaction, or do any other tasks. In other words, a functional requirement is WHAT an application must or must not do after some data input. Functional requirements are important as they show software developers how the system is intended to behave. If the system doesn’t meet functional requirements it means that it doesn’t work properly.

Function requirements determine the functions of an entire application or some (or even one) component. The three steps of a function are: data input, system behavior and data output. It can do a lot of things, such as calculating, manipulating data, carrying out business processes, and establishing user interaction. A functional requirement is what an application must or cannot do after some data input. Functional requirements show how the system is intended to work. The system doesn't work properly if it doesn't meet functional requirements. In other words, a functional requirement is WHAT the software should do.

What are non-functional requirements?

The performance and quality characteristics of software, such as system usability, effectiveness, security, and scalability, are considered non-functional requirements. For instance, a website must load in no more than 3 seconds and be able to serve more than 15 million people without seeing any performance issues. An app will still be able to carry out its essential tasks if non-functional requirements aren't met, but it won't be able to offer a satisfying user experience. Non-functional requirements are crucial because they aid in defining the system capabilities and restrictions necessary for producing high-quality software. Therefore, for effective product adoption, non-functional criteria are just as crucial as functional needs. In other words, a functional requirement is HOW the software should do.

How they differ?

The benefit of understanding the distinction between functional and non-functional requirements is that they specify the project's overall scope of work and budge. To create an application within the specified time and financial constraints, software engineers must stay current with this scope. The development team must prolong deadlines when the scope of the task is continually changing, which raises development expenses. This could have negative effects on a project.

When developing an MVP, it's critical to distinguish between the two categories of criteria. The features and functionality that should be included to the app first should be discussed by the development team and the client. A client could have his or her own ideas on the project's specifications. It's crucial to understand what kind of demand it is if a customer decides they want to remove or modify a feature. Software engineers can typically adjust non-functional needs with little effort, but functional requirements usually take more effort and significant modifications.

Where requirements comes from?

Customers should ideally have all the functional and non-functional requirements ready before contacting starting the development. Therefore, they must either seek a third party source or prepare them in advance on their own. These are some groups examples of functional requirements:

Business requirements: outline the project's objectives and expectations, potential advantages, potential restrictions, and scope.
User requirements – include the user's requirements and the system's capabilities for the user's activities.
System requirements – include system activities, hardware and software requirements, and other information

There is also some groups for non-functional requirements:

Availability – ensures that the software will operate reliably for a specific amount of time, such as with minimal downtime throughout the year.
Capacity – determines how much data or services the application can handle.
Performance – determines the app's speed.
Recoverability – assures that the app can restore the system to a specific set of parameters or recover all the data following a system failure.
Reliability – specifies that the application will operate without interruption in a specified environment or for a set amount of time.
Scalability – decides whether the app's functionality will remain unaffected by changes to its size or volume.
Security – establishes the level of security that the app should have, for instance, banking and fintech apps must adhere to national and international security standards.
Supportability – indicates whether the app is simple to support and maintain throughout its life cycle and what type of help is needed, such as an internal team or remote support.
Usability – determines how easily a user may interact with the app's interface, such as the color of the screen and the size of the buttons.

How can I express some requirements?

User Stories

It is standard procedure to write the requirements as user stories. User stories are the requirements that a user communicates. They typically take the shape of multiple short, repetitive sentences:

As a (user), I want to (goal) so that (reason).

When needed to explain or show to non-technical members, user stories are helpful and can explain easily most of the features and functionalities needed on the project.

Software Requirements Specification Document

A software development team can use the Software Requirements Specification (SRS) document to guide their work when developing an app. It contains a thorough explanation of all the features and functions of the product, as well as a compilation of all the customers' needs and wishes in a language that is understandable to the development team.

An SRS document typically has the following major sections:

Intro: a brief introduction that includes the goal of the product, a glossary of words, and references to relevant literature and resources for the development of the app
Description: description includes a thorough explanation of the characteristics of the product, coding guidelines, data interchange rules, and more.
Features: the section on system features, which describes how the features of the app should work.
Non-functional: Non-functional criteria include all performance benchmarks, the qualities of an app, and security specifications.

For efficient application development, user cases, user stories, and SRS generation are crucial. However, there are other documents that are just as crucial for the beginning and growth of a project.

Other tools

There are huge variety of tools and methodologies that could be applied for development. These are some that can be used, modified or even based on to create new ones.

Critical Rendering Path

Jeferson 'Shin' Leite Borges — Tue, 07 Feb 2023 12:23:01 +0000

What are these texts?
I was studing and for me to have some real study done I need to write it down, this is a small collection of topics that I studied in the last few weeks.
Other links from the same study-pool:

Branching Strategies > > - CI / CD

Critical Rendering Path

Requirements

Release Strategy

REST

Static Analysis

Web Security

Critical Rendering Path

The series of operations a browser performs to translate HTML, CSS, and JavaScript into visible pixels on the screen is known as the Critical Rendering Path (CRP). If we can improve that, our page will render more quickly.

The steps needed for the browser to render are:

Document Object Model(DOM)
CSS Object Model(CSSOM)
Render Tree
Layout
Paint

1. Document Object Model (DOM)

When we make request to a server, we get a response in the form of an HTTP message, which is divided into three parts: the start line, the header files, and the body. The body can include any arbitrary binary data (pictures, movies, and audio), and/or text, but the start line and headers are both text-based.

After receiving the answer (HTML markup language), the browser must translate all of the markup into what is typically displayed on screens. The browser starts by digesting the HTML and constructing the DOM according to a clearly defined set of steps.

Convert bytes to characters
Identify tokens
Convert tokens to nodes
Build DOM Tree

The string of characters converted from the bytes (if needed) will create the HTML body of the page. Something like:

<html>
  <head>
    <meta ...
    <title ...
    <link ...

Which are converted into tokens by the tokenizer, creating an token structure, the example below are just a reference and not a real tokenized HTML.

StartTag:head
Tag:meta
Tag:link
EndTag:head Hello...

While the tokenizer is converting the text into tokens, another function takes these tokens and converts them to Node objects. The Document Object Model, or DOM, is a tree structure that captures the content and properties of HTML as well as all the relationships between the nodes.

2. CSS Object Model (CSSOM)

Therefore, the DOM just records the page's content and not its associated CSS. We need to create the CSS Object Model in order to integrate CSS. The way CSSOM is built is very similar to how DOM is built.

However, we are unable to use the same incremental technique (partially generated CSS tree) as we did when building the DOM in this situation. Let's assume that we used partial CSS when building our page, for example p {background:'red'}, after some other part of the CSS we reach p {background:'blue'}, this operation overrides the previous one. If an incremental technique were used, this nodes would have a wrong color applied.

As a result, the browser stops page rendering until it has finished receiving and processing all of the CSS.

CSS IS RENDER BLOCKING

It is important to note that,

JAVASCRIPT IS PARSER BLOCKING

Because whenever we see the script tag in our HTML markup, it prevents the DOM from being constructed. As JavaScript may attempt to affect the page's style, Javascript should only be used after CSSOM creation.

JavaScript execution and CSS block rendering are both examples of this. Certain scripts don't alter the DOM or CSSOM, therefore they shouldn't prevent rendering. We employ async for those scripts so that they are not hindered by CSSOM or DOM creation.

3. Render Tree

After the tree structure and the styles (DOM and CSSOM) are calculated. The tree is finally rendered with all the styles correct applied. The components with characteristics like display:none are ignored because it only records visible content.

4. Layout

We need to determine where and how each element is placed on the page now that our render tree has been constructed. This is the stage of layout. The browser will execute the layout step each time we alter the geometry (width, height, and position) of elements.

5. Paint

The visible page content can finally be transformed to pixels in the paint phase so that it can be shown on the screen. In this process, the vector (boxes or forms created during the layout step) is converted to the raster (combination of individual pixels to be displayed on screen). This conversion is carried out by the rasterizer.

In most cases, one surface is painted. However, the browser will occasionally create various surfaces known as layers that can each be painted into separately. Once it is finished, the browser correctly merges all of the layers into one layer and displays them on the screen. Composite Layers is the name given to this procedure.

Usually all of these procedures occurs on the CPU, after all the layers are then send to the GPU that will make the drawing on the browser viewport.

The hardware will display a new image or frame for the user to see whenever the screen undergoes any form of visual change, such as scrolling or animation. Most devices refresh the screen at a rate of 60 frames per second (Hz), which is the standard.

Therefore, if we have 1000ms for 60 frames, we only have 16ms to produce each frame.
We typically only have 10 milliseconds because the browser uses the remaining time for other tasks.

If the process takes more than that, we can say that the page is laggy or janky.

Blocking the render

Order or blocking
Javascript > Style > Layout > Paint > Composite

Understanding exactly which parts of the pipeline our code activates is crucial because on each phase we can create some overhang that could cause a lag or jank.

CI / CD

Jeferson 'Shin' Leite Borges — Tue, 07 Feb 2023 12:22:29 +0000

What are these texts?
I was studing and for me to have some real study done I need to write it down, this is a small collection of topics that I studied in the last few weeks.
Other links from the same study-pool:

Branching Strategies > > - CI / CD

Critical Rendering Path

Requirements

Release Strategy

REST

Static Analysis

Web Security

What is CI / CD

CI/CD is a process that helps developers quickly and frequently deliver applications to customers by automating the development process. CI/CD is a software development practice that emphasizes continuous integration, continuous delivery, and continuous deployment.

CI/CD is a helpful solution for integrating new code, which can often cause problems for development and operations teams, it's also, a process that helps your software development team keep their applications running smoothly and efficiently by automating and monitoring them throughout the development process. The "CI/CD pipeline" is a collection of interconnected practices that are often used by development and operations teams working together in an agile way.

Continuous integration vs. delivery vs. deployment

The CI/CD has a few different meanings.

The "CI" always refers to continuous integration, is an automation process that developers use to keep their code bases up-to-date. Successful CI means that new code changes to an app are frequently built, tested, and merged to a shared repository. One way to avoid the problem of having multiple branches of an app in development that could conflict with each other is to use a solution like Git.

The "CD" refers to continuous delivery and/or continuous deployment, which are related concepts that sometimes get used interchangeably. Both are about automation, but they are also used to show how much automation is happening.

Continuous delivery means that changes to an application are automatically tested and uploaded to a repository, where they can be deployed to a live production environment by the operations or devops team. It is an answer to the problem of poor visibility and communication. It is the purpose of continuous delivery to make it easy to deploy new code.

CI/CD Flow

It is possible for CI/CD to specify just connected practices of continuous integration and continuous delivery, or it can also mean all connected practices of continuous integration, continuous delivery, and continuous deployment. Sometimes "continuous delivery" is used to make it more complicated because of the processes of continuous deployment as well. CI/CD is a process that involves adding a high degree of ongoing automation and continuous monitoring to app development, so it's probably not worth your time to get bogged down on specific definitions.

Case-by-case, what the terms refer to depends on how much automation has been built. Many enterprises start by adding CI, and then automate delivery and deployment down the road, for instance as part of cloud-native apps or just to enhance the process of the deployment.

Continuous integration, the CI

In modern application development, the goal is to have multiple developers working on the same app. If an organization is set up to merge all branching source code on a single day, the resulting work can be tedious, manual, and time-intensive. There is a chance that a change to an application will conflict with other changes made by other developers. The problem can be further compounded if each developer has their own IDE settings, instead of the team agreeing on a single cloud-based IDE, or sharing the same settings for all the IDEs.

The integration should happen on a daily basis, or in the best, multiple times a day. Once a developer's changes to an application are merged, those changes are validated by automatically building the application and running different levels of automated tests, to ensure the changes haven't broken the app. The entire app needs to be tested, from classes to the different modules. Continuous integration makes it easier to fix bugs when automated testing discovers a conflict between new and existing code.

Continuous delivery, the CD

Continuous delivery streamlines the release of code to a repository following the automation of builds and unit and integration testing. In order to have an effective continuous delivery process, it is important that continuous integration is built into the development process. The goal of continuous delivery is to have a codebase that is always ready for deployment to a production environment. This involves test automation and code release automation from the merge of code changes to the delivery of production ready builds. The operations team is able to deploy an app quickly and easily at the end of the process.

Continuous deployment, the other CD

Continuous deployment is the final stage of a mature CI/CD pipelines. Continuous delivery is an extension of continuous deployment, which automatically releases a production ready build to a code repository. Continuous deployment relies heavily on well-designed test automation because there is no manual gate at the stage.

Continuous deployment means that a change to a cloud application can be made within minutes if it passes automated testing. It's easier to receive and incorporate user feedback now. It is easier to release changes to apps in small pieces, rather than all at once, as a result of all of these connected CI/CD practices. There is a lot of upfront investment since automated tests will need to be written to accommodate a variety of testing and release stages.

What are some common CI/CD tools?

A team can automate their development, deployment, and testing with CI/CD tools. Some tools specifically handle integration, some manage development and deployment, and others specialize in continuous testing or related functions. Currently most of the repository solutions already have some level of CI/CD integrated, like Gitlab CI/CD, Github Actions and others.

There is also other tools that automate the process like Jenkins, TravisCI, Spinnaker, GoCD, Concource and Screwdrivers. All these solutions provides almost the same level of CI and CD for most of the projects. At the end of the day, does not matter what specific tool is used as long there is a process for the CI and CD on the project and most of the deployment can be automated.

Branching Strategies

Jeferson 'Shin' Leite Borges — Tue, 07 Feb 2023 12:21:21 +0000

What are these texts?
I was studing and for me to have some real study done I need to write it down, this is a small collection of topics that I studied in the last few weeks.
Other links from the same study-pool:

Branching Strategies > > - CI / CD

Critical Rendering Path

Requirements

Release Strategy

REST

Static Analysis

Web Security

What is branching strategies

Git is a common version control system used in many organizations, and branches are often used as a way for teams to develop features separately.

These branches are usually merged or rebased back to a master branch once the work is completed. This way, the features (and any bug fixes) are kept separate from each other allowing you to fix bugs more easily.

Branches protect the mainline of code, and any changes made to a branch don't affect other developers. A branching strategy is the way that software development teams use version control when writing, merging and deploying code.

Even though branches aren't strictly limited to Git, I'll primarily use Git for version control. Before we discuss different branching strategies, let's take a look at how Git actually works and why it is such a popular source control system.

Why you need a branching strategy

A branching strategy is essential to avoid conflicts when merging changes and to make it easier to integrate changes into the master branch.

A branching strategy aims to:

To maximize productivity, ensure that developers are working in a coordinated fashion.

Allows parallel development
Organize a series of planned, structured releases
Created a path to follow on the process to create and merge
Improves the ability to create a more coherent environment for releases

Here some common strategies

GitFlow

GitFlow is a powerful development workflow that enables parallel development where developers work on features on different branches from the master branch. This makes it easier to manage features and keep them consistent. Later, when the changes are complete, the developers merge those changes back into the master branch for release.

This branching strategy consists of the following branches:

Master: The main code to be release. This code should be production ready.
Develop: This is a intermediary branch for testing, QA or any other usage before release a new version of the software.
Feature: to develop new features, you should branch off the develop branch. This is not a single branch. Every feature should have its own branch.
Release: to prepare a new production release, you typically branch from the develop branch and merge back to both develop and master.
Hotfix: is created when a bug is discovered and needs to be fixed. This allows developers to continue working on their own changes on the develop branch while the bug is being fixed. This branch is typically derived from the master.

The master branch is considered to be the most important branch, with an infinite lifetime. The other branches are meant to help developers work together more effectively, usually lasting only a short time.

Pros and Cons

This model allows for parallel development to protect the production code, so the main branch remains stable for release while developers work on separate branches. Adding more branches can lead to multiple versions of the code being maintained, which can become difficult to manage as developers merge their changes from the development branch to the main.

Developers will need to create a release branch first, then make sure any final work is also merged back into the development branch and then that release branch will need to be merged into the main branch.

GitHub Flow

This is a simpler version of GitFlow designed for smaller teams. It doesn't require managing multiple versions, making it ideal for smaller teams. This model doesn't use release branches.

Starting with the master branch, developers create branches, feature branches, which are isolated from the master and used for their own work. These branches are then merged back into the main branch. The feature branch is deleted. This model keeps the master code in a deployable state so that it can support continuous integration and continuous delivery processes.

Pros and Cons

It is heavily based on the Agile principles, which makes it a fast, streamlined branching strategy that uses short production cycles and frequent releases. This strategy allows for fast feedback loops so that teams can quickly identify and solve issues.

If a development strategy doesn't have multiple development branches, it's more susceptible to bugs and can lead to an unstable production code if bug fixes happen in the main branch. The master branch can become cluttered because it is used for both production and development.

The model is more suited for smaller teams, and as teams grow they may experience merge conflicts as everyone is merging to the same branch. This can be problematic as developers can't see what other developers are working on, leading to potential conflicts.

GitLab Flow

GitLab Flow is a simpler alternative to GitFlow that allows for feature-driven development and feature branching with issue tracking. GitFlow helps developers create a develop branch and use that as the default, while GitLab Flow works with the main branch right away.

Pros and Cons

If you want to keep multiple environments and want to have a staging environment separate from the production environment, this is a great solution. Whenever the development branch is ready for release, you can merge back into the production branch and release it.

This strategy allows developers to maintain separate versions of software in different environments, providing proper isolation. GitLab Flow assumes that you can deploy your code into production whenever you merge a feature branch into the master branch, but GitLab Flow also allows your code to pass through internal environments before it reaches production.

Trunk-based development

Trunk-based development is a branching strategy that, in fact, doesn't require any branches. Developers integrate their changes into a shared trunk at least once a day. The trunk shared between the all of the developers should be ready for release at any time.

The key to successful Git development is to make frequent, smaller changes. This helps limit the number of long-lasting branches and avoids merge conflicts, which ensures that all developers are working on the same branch.

In other words, developers commit directly to the trunk without using branches. Feature flags are a common strategy for controlling which features are enabled in a software application. Because the trunk is always ready for release, feature flags help separate deployment from release, so any changes that aren't ready can be wrapped in a feature flag and hidden while completed features and can be released to end users without delay.

Pros and Cons

Continuous integration is a powerful tool for managing changes to a project's source code. Trunk-based development makes it easy to keep the trunk up to date, which makes it easy to test changes and ensure that the project is running smoothly.

Developers can collaborate more easily by viewing changes other developers make directly in the trunk without the need for branches. This is different from other branching methods where each developer works independently in their own branch and any changes that occur in that branch can only be seen after merging into the main branch.

Trunk-based development eliminates the stress of long-lived branches because it doesn't require branches, and merge conflicts or so-called "merge hell" because developers push small changes frequently. This will help to avoid any conflicts that may arise.

This strategy is better suited for more experienced developers, as it offers a lot of autonomy. This might be intimidating for inexperienced developers, who are interacting directly with the shared trunk. If you are a less experienced team, you may want to use a Git branching strategy.

The pain of upgrading software

Jeferson 'Shin' Leite Borges — Sun, 11 Sep 2022 08:26:36 +0000

Ok, I'll try to write this post in both portuguese and english.

English

Okay, I'm toying with this little project to make a simple little game, with some metroidvania elements (because of reaons) using the Godot Engine behind the scenes to learn Game Design elements and of course, sharpen my knowledge on other platforms.

Like everyone, I'm all waiting for the long-awaited version 4 of the engine, still there is some alpha versions have been released recently that are stable enough to play with and learn what's next in the engine.

Not only that, I can also provide one or two collaborations on the documentation to improve or even just make it a little clearer.

And like every software update, we have some pains, and with them comes bilateral thinking:

On the one hand, I can progress with the development of the game in the current version which is stable and ready for production (not that I care about that for a hobby project), I already have most of the elements I need ready to use, it's a matter of adding only the missing details (other enemies, level designing other areas...)

On the other hand, I know that there are some parts of the code that I made that are not good, some paradigms that I shouldn't have used, and of course, many improvements that I learned throughout this experiment. If I would start the project from scratch I will be much more able to do something better for my dev experience than I had when I started the project.

Now the problem,

Even if I had a button: "update version" and everything is updated and working perfectly, my accumulated errors will still carry the weight in development.

And since I have the opportunity to review the code (to update the GDScript version), I could in theory update my past mistakes and make it more fit for the future "Shin" not swearing to present "Shin" so much.

This is the pain of updating the software, as it's a hobby project, and it's going to affect maybe 3 people at most, that won't be a problem, doing everything from scratch.

But dealing with larger software, where it affects many people, that thought is clearly seen. As a result, I can see in the industry a lot of stuff being used from 10, 20 years ago, and nobody changes anything because updating will bring pain.

Anyway, this is a small rant, and to remind me that I will continue to develop the same game, but I will update to the new version of the engine.

Wish me luck with the crazy choice I'm making.

Ps.: And that way the game will never be officially finished, becoming another project for the drawer.

Português

Certo, eu to brincando com esse pequeno project de fazer um joguinho simples, com alguns elementos de metroidvania (porque sim) usando o Godot Engine por trás dos panos para aprender elementos de Game Design e claro, afiar meus conhecimentos em outras plataformas.

E como todos eu estou aguardando a tão esperada versão 4 da engine, a questão é que recentemente tem sido liberadas versões alpha que estão estáveis o bastante para brincar e aprender o que vem por aí na engine.

Não apenas isso, também posso perceber uma ou outra colaboração que posso fazer na documentação para aprimorar ou mesmo apenas deixar ela um pouco mais clara.

E como toda atualização de software, temos algumas dores, e com elas venho o pensamento bilateral:

De um lado, eu tenho como progredir com o desenvolvimento do jogo na versão atual que é estável e pronta para produção (não que eu me importe com isso para um project de hobby), tenho já boa parte dos elementos que preciso prontos para uso, é uma questão de adicionar somente os detalhes que faltam (outros inimigos, fazer o level design de outras áreas...)

Do outro lado, eu sei que tem algumas partes do código que fiz que não está legal, alguns paradigmas que não deveria ter usado, e claro, muitas melhorias que eu aprendi ao longo desse experimento. Como sempre se eu começar o projeto do zero terei muito mais capacidade de fazer algo melhor para minha experiência de dev do que tinha quando comecei o projeto.

Agora o problema,

Mesmo que tivesse um botão: "atualize a versão" e tudo seja atualizado e funcionando perfeitamente, meus erros acumulados ainda terão o peso no desenvolvimento.

E como eu tenho a oportunidade de revisar o código (para autalizar a versão do GDScript), eu poderia em teoria atualizar meus erros do passado e deixar ele mais apto para o futuro "Shin" não xingar tanto o "Shin" do presente.

E esta é a dor de atualizar o software, como é um projeto de hobby, e vai afetar talvez 3 pessoas no máximo, isso não será um problema, fazer tudo do zero.

Mas quando se pensa em software maior, onde afeta muitas pessoas, esse pensamento claramente é visto. Resultado pelo qual consigo ver na indústria muita coisa sendo usada de 10, 20 anos atrás, e ninguém muda nada porque atualizar vai trazer dores.

De qualquer forma, esse é um pequeno desabafo, e para me lembrar que eu irei continuar desenvolvendo o mesmo jogo, mas irei atualizar para a versão nova da engine.

Me desejem sorte pela escolha maluca que estou tomando.

Ps.: E dessa forma o jogo nunca será oficialmente terminado, se tornando mais um projeto para a gaveta.

(() => ())()

SignalBus?

Jeferson 'Shin' Leite Borges — Mon, 08 Aug 2022 08:10:06 +0000

Ok, I'll try to write this post in both portuguese and english.

English

Let's go!

What is a SignalBus and why all this noise in my head when I think about this pattern and more importantly, how to implement it in Godot?

So what's the concept on this one?

Imagine the situation, you made your UI all beautiful and wonderful, you have your level all built up, you even have points to spawn the character throughout the level. Everything is perfect, then you need to connect the player and his life points with the UI.

The initial thought comes to mind, "This is a job for signals!", so at your level you locate the player's node and then connect it to UI. Everything works, but now you have a code snippet somewhere (level, player, or UI) that you need to know everyone's details and organize.

So this code is entangled.

For small games, this is not a problem, and particularly, until well advanced in my development I didn't experience any problems, and the solution seemed to me even elegant.

But I've this itch in my head, this noise in my brain, this might be better, but how?

It was then that I heard the term SignalBus. Now we have a problem and we're going to solve the problem a little more elegantly, and then we're going to think about the implications of that.

In this case we have a Singleton, which for the engine is done just by creating a script (which we will call SignalBus.gd and add the list of auto-loads, that way the script will always be running and it can be called in any other script.

Let's then add something very interesting to our friend signal bus, for example:

#SignalBus.gd
extends Node2D

signal PlayerDamaged(total_hp, current_hp)

Pretty short, right?
But what about our player friend?

#Player.gd
class_name Player extends KinematicBody2D
#...
func receive_damage(damage):
  #...
  SignalBus.emit("PlayerDamaged", max_hp, current_hp)
  #...
#...

As you can see, the player class only knows about SignalBus, but it doesn't know the UI, it doesn't know the level, and honestly, it doesn't need to. The level also no longer needs to know the player, let alone the UI.

Now let's see the UI class,

#UI.gd
class_name UI extends Control
#...
func _ready(damage):
  #...
  SignalBus.connect("PlayerDamaged", self, "on_update_player_life")
  #...
func on_update_player_life(max, curr):
  # Update ui with actual values
#...

Now we have a code that is only coupled to SignalBus, with that we can move things to other places and even put more things listening to the player signal.

Imagine that we now have an enemy that waits to hear the player take damage and then shoots? Or we need to put a new animation of shaking the screen when the player takes damage, all this can be done by the same signal that is controlled by our friend bus.

Português

Vamos lá,

O que é um SignalBus e porque todo esse barulho em minha cabeça quando penso nesse padrão e o mais importante, como implementar ele em Godot?

Qual a idea por trás?

Imagine a situação, você fez sua UI toda linda e maravilhosa, você tem seu nível todo construido, você tem até pontos para nascer o personagem ao longo da fase. Tudo é perfeito, aí você precisa conectar o jogador e seus pontos de vida com a UI.

Em seu pensamento inicial vem a mente, "Isso é um trabalho para sinais!", então na sua nível você localiza o nó do jogador e então conecta junto a UI. Tudo funciona, mas agora você tem um trecho de código em algum lugar (nível, jogador ou UI) que precisa saber dos detalhes de todo mundo e organizar.

Ou seja, acoplamento de código.

Para jogos pequenos, isso não é um problema, e particularmente, até bem avançado no meu desenvolvimento eu não senti problemas, e a solução me pareceu até mesmo elegante.

Mas eu tinha essa pulga atrás da orelha pensando, isso pode ser melhor, mas como?

Foi então que ouvi o termo SignalBus. Agora temos um problema e iremos a solução do problema um pouco mais elegante, e depois vamos pensar nas implicações disso.

Nesse caso temos um Singleton, que para a engine é feito apenas por criar um script (que vamos chamar de SignalBus.gd e adicionar a lista de auto-loads, dessa forma o script vai estar sempre em execução e se pode ser chamado em qualquer outro script.

Vamos então adicionar algo bem interessante no nosso amigo busão de sinais, segue o exemplo:

#SignalBus.gd
extends Node2D

signal PlayerDamaged(total_hp, current_hp)

Bem curtinho, né?
Mas e o nosso amigo jogador?

#Player.gd
class_name Player extends KinematicBody2D
#...
func receive_damage(damage):
  #...
  SignalBus.emit("PlayerDamaged", max_hp, current_hp)
  #...
#...

Como se pode ver, a classe do jogador conhece apenas do SignalBus, mas não conhece o UI, nem conhece o nível, e sinceramente, não precisa. O nível também não precisa mais conhecer o jogador, e muito menos o UI.

Agora vmaos a classe do UI,

#UI.gd
class_name UI extends Control
#...
func _ready(damage):
  #...
  SignalBus.connect("PlayerDamaged", self, "on_update_player_life")
  #...
func on_update_player_life(max, curr):
  # Update ui with actual values
#...

Agora temos um código que está acoplado apenas no SignalBus, com isso podemos mover coisas para outros lugares e inclusive colocar mais coisas ouvindo o sinal do player.

Imagine que agora temos um inimigo que espera ouvir o jogador receber dano para então atirar? Ou precisamos colocar uma nova animação de tremer a tela quando o jogador receber dano, tudo isso pode ser feito pelo mesmo sinal que é controlado pelo nosso amigo bus.

Espero que tenha gostado desse trecho.

(()=>())()