DEV Community: Alan Patrick

OOP, the right way: Message Passing and the Four Pillars

Alan Patrick — Mon, 22 Jan 2024 13:08:06 +0000

I just watched an old video of ThePrimeagen about message passing in OOP, and I wanted to write an article that explained the topic better. So here we are.

Message passing, for those who don't know, is essentially a trigger for an object to act. Somehow, "message passing" became "method calls". Javascript, despite not being Smalltalk, already has a nice mechanism for messages, though. You can access an object's fields dynamically:

obj['message'](...params);

This allows you to access the behavior associated with the message. Behavior is not the same as a method call. Behaviors can be many private methods at once, public methods or even reference usage of other objects. What matters is the declarative API that message passing enables. This attains the principle of Abstraction.

const jose = new Person('José');

jose['greet'](); // prints "Hello, I am José!"
jose['sum'](2, 2); // prints "I am bad at math!!!"

If we give the same message to different objects, what happens? We get Polymorphism.

const jose = new Person('José');
const fusca = new Car('Fusca');
const pimenta = new Dog('Pimenta');

jose['greet'](); // prints "Hello, I am José!"
fusca['greet'](); // prints "Beep!"
pimenta['greet'](); // prints "Woof!"

To teach José some math, we can't simply open José's brain and shove math inside it — it isn't how brains work in real life, so it won't be how we model our system here. José will be properly taught. Let's introduce him to Maria, a teacher:

const jose = new Person('José');
const maria = new Teacher('Maria'); // Note the new class

maria['greet'](jose); // prints "Hello, José, I am Maria!"

jose['greet-back'](maria); // prints "Hello, Maria, nice to meet you!"

// José even knows how to `greet-back` — how fancy.

See how the greet message is different this time? Behaviors can be modified with parameters. This is also a great example of the principle of Inheritance: A teacher is a person, and all persons know how to greet. Maria, being a teacher and person, knows how to greet too.

Finally, let's teach José some math:

// Checking again if José knows math:

jose['sum'](2, 2); // prints "I am bad at math!!!" still!

// Nothing new. Let's have Maria to teach him:
maria['teach'](jose, 'math');

jose['sum'](2, 2); // prints "2 plus 2 is 4."

What happened with José? Did Maria just shove math into his brain? Let's take a look at the teach behavior below. Since objects cannot change the state of other objects, you must pass the message and let them deal with it.

class Teacher extends Person {
  // ... other logic goes here

  teach(person, subject) {
    person['learn'](subject);
  }
}

That rule of not touching the internal state of another object is called Encapsulation. Only José can truly learn — Maria can only help. José is a good student and, now that he knows math, he behaves differently when prompted to sum two numbers.

And there you have it: We explored the four pillars of Object Oriented Programming through the lenses of Message Passing.

Hope you enjoyed it!

OOP do jeito certo: Passagem de Mensagem e os Quatro Pilares

Alan Patrick — Mon, 22 Jan 2024 13:07:55 +0000

Acabei de assistir um vídeo antigo do ThePrimeagen sobre passagem de mensagens na OOP, e quis escrever um artigo que explicasse melhor o tópico. Enãto aqui estamos.

Passagem de mensagens, para aqueles que não sabem, é essencialmente um gatilho para um objeto agir. De alguma forma, "passagem de mensagens" tornou-se "evocação de métodos". JavaScript, apesar de não ser Smalltalk, já possui um mecanismo interessante para mensagens. Você pode acessar dinamicamente os campos de um objeto:

obj['mensagem'](...params);

Isso permite que você acesse o comportamento associado à mensagem. Comportamento não é o mesmo que uma chamada de método. Comportamentos podem ser muitos métodos privados de uma vez, métodos públicos ou até mesmo uso de referência de outros objetos. O importante é a API declarativa que a passagem de mensagens possibilita. Isso enforça o princípio da Abstração.

const jose = new Pessoa('José');

jose['saudacao'](); // imprime "Olá, eu sou o José!"
jose['soma'](2, 2); // imprime "Eu sou ruim em matemática!!!"

Se dermos a mesma mensagem para diferentes objetos, o que acontece? Obtemos Polimorfismo.

const jose = new Pessoa('José');
const fusca = new Carro('Fusca');
const pimenta = new Cachorro('Pimenta');

jose['saudacao'](); // imprime "Olá, eu sou o José!"
fusca['saudacao'](); // imprime "Beep!"
pimenta['saudacao'](); // imprime "Au Au!"

Para ensinar matemática a José, não podemos simplesmente abrir o cérebro dele e enfiar matemática lá dentro — não é assim que o cérebro funciona na vida real, então não será assim que modelaremos nosso sistema aqui. José será ensinado corretamente. Vamos apresentá-lo à Maria, uma professora:

const jose = new Pessoa('José');
const maria = uma Professora('Maria'); // Note a nova classe

maria['saudacao'](jose); // imprime "Olá, José, eu sou a Maria!"

jose['saudacao-de-volta'](maria); // imprime "Olá, Maria, prazer em conhecê-la!"

// José até sabe como `saudar-de-volta` — que chique.

Vê como a mensagem saudacao é diferente desta vez? Comportamentos podem ser modificados com parâmetros. Este é também um ótimo exemplo do princípio de Herança: Um professor é uma pessoa, e todas as pessoas sabem como saudar. Maria, sendo professora e pessoa, sabe como saudar também.

Finalmente, vamos ensinar matemática para José:

// Verificando novamente se José sabe matemática:

jose['soma'](2, 2); // imprime "Eu sou ruim em matemática!!!" ainda!

// Nada de novo. Vamos fazer Maria ensiná-lo:
maria['ensinar'](jose, 'matemática');

jose['soma'](2, 2); // imprime "2 mais 2 são 4."

O que aconteceu com José? Maria simplesmente enfiou matemática em seu cérebro? Vamos dar uma olhada no comportamento ensinar abaixo. Como objetos não podem mudar o estado de outros objetos, você deve passar a mensagem e deixá-los lidar com isso.

class Professor extends Pessoa {
  // ... outras lógicas vão aqui

  ensinar(pessoa, assunto) {
    pessoa['aprender'](assunto);
  }
}

Essa regra de não mexer no estado interno de outro objeto é chamada de Encapsulamento. Apenas José pode realmente aprender — Maria só pode ajudar. José é um bom aluno e, agora que ele sabe matemática, ele se comporta de maneira diferente quando é pedido para somar dois números.

E aí está: exploramos os quatro pilares da Programação Orientada a Objetos através da Passagem de Mensagens.

Espero que tenha gostado!

From a Zettelkasten noob to another: Just Start

Alan Patrick — Wed, 10 Jan 2024 13:38:57 +0000

I have been thinking about how to approach my zettelkasten journey. I got the impression that creating more metadata was a good move. It would allow me to manipulate and organize notes better, as well as understand the full context of the aggregate of notes I built.

More metadata means more complexity. More cognitive overhead. More time away from the notes that truly matter. For example, I started thinking about creating a whole new piece of software, that used clever database shenanigans for dynamic tag editing and retroactive metadata updates. This is a lot of stuff. Do I really need it?

I started to pay more attention to what I believe is the essence of the workflow of zettelkasten:

Write one note.
Write another note.
If the two notes are related, link them.
Keep on linking all notes that are related.
Write index notes to indirectly link notes that are related, but not necessarily connected.

This understanding may be a little flawed, but showed me that you need very little for a successful zettelkasten. All you need are notes that reference others notes. No tags, no project-related-link, nada.

And another thing: Thinking too deeply about this things paralises you with analysis. This paralysis stops you from messing up. Messing up is a vital component in your learning journey. The desire to avoid messing up is understandable, but you can't avoid it. Messing up is how you learn. Don't run from that, embrace it.

If the way you take notes changes across time, embrace that as an exciting view on how you evolve. Keep things simple. Don't avoid messing up. Appreciate your development journey.

Just write a damn note and stop overthinking things, you damn nerd!

What do you guys think? What tips do you have? Please share!

Image by macrovector on Freepik

Minha experiência com meditação

Alan Patrick — Fri, 15 Sep 2023 20:03:06 +0000

Meditação é difícil. Especialmente sem mentores por perto. A internet possui tanta informação que é fácil se perder e você precisa de tempo para se achar. Eu li uns livros. Livros de budismo, zen, até Tolle. Sentei em lotus e tive a perna formigando. Comecei, desisiti, recomecei, redesisti. Meditei de 30 segundos a 20 minutos. Não cheguei a usar mantras, mas tenho bastante conhecimento de como minha respiração funciona.

Conclusão? Vale a pena. Não é milagroso, mas é um avanço na qualidade de vida. Um avanço tímido e sutil. Consigo me pegar em momentos que a mente tomaria conta e, em vez de fazer besteira, respiro fundo. Espero que melhore minha vida ainda mais, quando tiver mais prática. Quero ficar mais sereno e silencioso por mais tempo.

Uma coisa esquisita que percebi é como posso usar meditação ao meu favor. Estou no processo de cortar uso excessivo de tecnologia e a meditação ajuda nisso. Agora, em vez de abrir o youtube ou o (antigo) twitter, olho pro teto. Em vez de ler enquanto faço uma refeição, o plano é simplesmente soltar a mente e prestar atenção na comida.

Quando não se está distraído o tempo todo, a vida tem um aspecto diferente, inquietante. Especialmente se não tiver ninguém por perto, apenas você e o lugar. Meditação é difícil. Mas vale a pena.

Crie um sistema automático de backup no Ubuntu com bash e crontab

Alan Patrick — Sun, 25 Dec 2022 23:17:55 +0000

Existe um monte de coisas legais que podem ser feitas com scripts! Uma coisa que sempre quis fazer é criar um sistema de backup que roda automaticamente em um certo ponto do dia. Agora que descobri como fazer, vou lhes mostar como criar um script com os comandosrsync e crontab.

Passo 0: Tudo começa com um BANG

Crie um script chamado fazBackup.sh, contendo algo assim:

#!/bin/bash

echo Inicializando script de backup.

O comentário #!/bin/bash é uma diretiva que anuncia que interpretador deve ser usado. Neste caso, o interpretador é o bash, mas poderia ser python ou node. Tal diretiva é chamada de shebang.

Precisamos de um script executável, o que significa a necessidade de permissão para execução. Para modificar tal política, usamos o comando chmod. Este comando tem duas formas de adotar novas políticas: números e letras. Aqui será usado a forma de letras e todos os usuários serão capazes de executar o script. (Para saber mais sobre o chmod, aqui) está a documentação em inglês.)

No terminal, escreva:

chmod a+x makebackup.sh
# a means all users
# + means adding a permission (a minus (-) would be removing it).
# x means permission to execute

Passo 1: De onde veio, pra onde foi

Nós usaremos o rsync para copiar os items, porém você poderia usar outras ferramentas, como o commando cp. Para aprender mais sobre o rsync, leia esse tutorial (em inglês).

Dentro do fazBackup.sh, escreva o seguinte:

#!/bin/bash
echo Inicializando script de backup.

rsync [Fontes] /caminho/para/[Destino]/
# Fontes são todos os arquivos e pastas a serem guardados
# Destino é a pasta onde o backup será guardado

echo Backup finalizado. Teminando script.

Lembrete! A pasta de [Destino] não precisa existir previamente, pois rsync cria a pasta no diretório. Tudo o que precisa fazer é colocar o nome desejado, seguindo por uma barra ('/').

Step 2: Tenho um trabalho pra você

Antes de configurar o cronjob, você precisa definir a agenda. Quando que o backup deve ser feito? Use a ferramenta Crontab Guru para decidir quando você quer o trabalho feito — diariamente, semanalmente, mensalment, etc.

Depois, você configura o cronjob, que é bem fácil! Digite crontab -e no terminal, e ele abrirá um crontab com umas informações bacanas — vale a pena dar uma olhada. Dentro desse arquivo, vá ao final, cole a data que você criou no Crontab Guru, e escreva todo o caminho absoluto para o script executável. Algo assim:

# Crontab file
00 10 * * * /caminho/para/fazBackup.sh

Passo 3: E fim

E pronto! Teu script de backup está automatizado.

Uns avisos e considerações

O serviço cron leva um ou dois minutos para atualizar, então se você quiser testar imediatamente, mantenha o timing em mente: coloque a execução do script uns 3 minutos depois de salvar o crontab.

Outra coisa a saber: você poderia agendar o comando tar, em vez de criar um script personalizado. Ficaria algo como:

# Crontab
# at 10:30 am, everyday, do
30 10 * * * tar cvzf /caminho/para/arquivo_de_saida.tar.gz /caminho/para/diretorio_de_entrada/

Conclusion

Espero que este artigo tenha ajudado! O serviço cron é bastante poderoso, assim como é o scripting em bash. Você pode criar todos tipos de tarefas agendadas e tornar sua máquina linux num mordomo pessoal! Se tiver ideas do que mais pode ser feito com cron ou sugestões de melhoria para este artigo, comente abaixo!

Create an automatic backup system on Ubuntu with bash, rsync and crontab

Alan Patrick — Sun, 25 Dec 2022 23:14:35 +0000

There is a lot of cool things you can do with scripts! One thing I always wanted to do is create a backup system that runs automatically at a certain point of the day. Here is how I made the script using rsync and crontab commands.

Step 0: It all starts with a BANG

Create a script named makebackup.sh like this:

#!/bin/bash

echo Initializing backup script.

The #!/bin/bash comment is a directive that announces which interpreter to use. In this case, the interpreter is bash, but could be others, like python or node. This directive is called a shebang.

We need an executable script, which means it needs permission to be executed. To change the permissions of a file, you need the chmod command. This command has two ways of receiving new permission policies: numbers and letters. We will use the letter system, and let all users to be capable of executing the script. (There is a good guide for chmod here).

On the terminal, write:

chmod a+x makebackup.sh
# a means all users
# + means adding a permission (a minus (-) would be removing it).
# x means permission to execute

Step 1: Where will it come from, where will it go

We will be using rsync for copying the items, but you could use other tools, like the cp command. To learn more about rsync, click here.

Within the makebackup.sh script, write the following:

#!/bin/bash
echo Initializing backup script

rsync [Sources] /path/to/[Destination]/
# Sources are all files and folders to back up
# Destination is the folder to store the backups

echo Backup finised. Exiting script.

Keep in mind! The [Destination] folder doesn't need to already be there, because rsync creates it for you, if inexistent. All you need is to name the desired output directory. Do not forget the forward slash at the end, though, to indicate that it is a folder.

Step 2: I got a job for you

Before you set up the cronjob, you have to decide on the schedule. When should things be backed up? Use the Crontab Guru tool for deciding when you want the job done — daily, weekly, monthly, etc.

Then, you set up cronjob, which is really easy! Type crontab -e on the terminal, and it will open a crontab with some nice information — do skim it, at least. Within the file, go to the bottom, paste the schedule you got from Crontab Guru, and type out the full path to your executable script. Something like this:

# Crontab file
00 10 * * * /path/to/makebackup.sh

Step 3: The End

And this is it! Your backup script is automated.

Some warnings and considerations

The cron service takes 1 or 2 minutes to reload, so if you want to test immediately, keep the timing in mind: set the execution of the cronjob for at least 3 minutes from saving the crontab file.

Another thing to keep in mind is this: you could schedule a tar command, instead of creating a custom script. It would look something like this:

# Crontab
# at 10:30 am, everyday, do
30 10 * * * tar cvzf /path/to/archive_name.tar.gz /path/to/input_directory/

Conclusion

I hope this was helpful! The cron service is really powerful, and so is bash scripting. You can create all kinds of scheduled tasks and make your ubuntu machine to be a personal butler! If you have any ideas of what else can be done with cron or suggestions for improving this article, please comment below!

Three concepts of the styled-components library

Alan Patrick — Mon, 25 Jul 2022 18:49:03 +0000

Introduction

Lately, I've been playing with styled-components. It is a CSS-in-JS library that uses tagged template literals. I want to talk about three concepts that I got puzzled by: Interpolation, GlobalStyle and ThemeProvider.

What is Interpolation?

Interpolation is adapting a component based on the props passed to it; meaning, you can inject values through props. For example:

const MockElement = styled.div`
  --size: ${(props) => (props.big ? '100px' : '50px')};
  width: var(--size);
  height: var(--size);
  background-color: yellowgreen;
`;

render(
  <div>
    // This renders a 50x50 square, because there was no "big" prop
    <MockElement />
    // This renders a 100x100 square, because "big" was passed
    <MockElement big />
  <div>
)

So you can use props as truthy values. What about custom values? That works too!

const MockElement = styled.div`
  background-color: ${props => props.color ? props.color : 'yellowgreen'};

  --size: ${(props) => (props.big ? '100px' : '50px')};
  width: var(--size);
  height: var(--size);
`;

render(
  <div>
    // This renders a blue square
    <MockElement color='blue'/>
    // This renders... no color??
    <MockElement color />
  <div>
)

Styled props are truthy by default, but since no value was passed, nothing gets rendered. To use the default value with this technique, you either skip the prop entirely, or you pass a null.

But BEWARE! You must pass a function when interpolating a value, or the code breaks. Something like the following wouldn't work:

const MockElement = styled.div`
  background-color: ${props.color}; /* It must be a function */
`;

Must the function be inline? No! You can simply pass any function as a callback:

function declaredFunction (props) {
  let scale = `${props.factor * 50}px`
  return scale
}

const MockElement = styled.div`
  --size: ${declaredFunction};
  width: var(--size);
  height: var(--size);
  background-color: ${props => props.color ? props.color : 'yellowgreen'};
`;

render(
  <div>
    // This renders a 150x150, yellowgreen square
    <MockElement big color={null} factor={3}/>
  <div>
)

This marks the end of exploring interpolation. On to the next!

What is GlobalStyle?

Self-explanatory as the name is, a GlobalStyle component is used to define general styling rules for the application. A close comparison would be using an index.css file that gets imported and bundled before all other stylesheets, thus being overwritten by css modules that follow it later.

Using a global style is fairly simple! First, you must create the GlobalStyle.js file, like so:

import { createGlobalStyle } from 'style-components';

const GlobalStyle = createGlobalStyle`
  /* Insert global styling here */
`;

export default GlobalStyle;

Then, put the component...anywhere, really. At least, in the few tests I did, I put the component anywhere within the project and it worked just fine. However, for the sake of organization, I've put in my routing system (with react-router), like so:

# App.js

import GlobalStyle from './utils/GlobalStyle';

function App() {
  return (
    <BrowserRouter>
      <GlobalStyle />
      <Routes>
        {/*The routes and elements go here*/}
      </Routes>
    </BrowserRouter>
  );
}

Cool! On to the final topic: ThemeProvider.

What is ThemeProvider?

ThemeProvider is a source of universal props to all its children. You must put the component at the root of your project, if you want all components to have access to it.

So, if you use App.js as your root, you could do something like:

#App.js
import { ThemeProvider } from 'styled-components';

const themeObject = {
  button : {
    primary : {
      background: 'lightblue',
      color: 'white',
    },
    secondary: {
      /* other keywords*/
    }
  }
}

function App() {
  return (
    <ThemeProvider theme={themeObject}>
      <CoolButton />
    </ThemeProvider>
  );
}

That themeObject becomes accessible to all objects that are children of ThemeProvider. You use the theme prop through interpolation, like this:

#CoolButton.styled.js
import styled from 'styled-components';

const CoolButton = styled.button`
  background-color: ${props => props.theme.button.primary.background};
  /* As seen above and below, you just need to access the string from the theme object */
  color: ${props => props.theme.button.primary.color};
`

You can also combine all three components, by making GlobalComponent a child of ThemeProvider and interpolating values as needed. One useful example is setting the font family.

# theme.js

const theme = {
  heading: "Cool Heading",
  subHeading: "Cute Heading"
};

export default theme;

# GlobalStyle.js

import { createGlobalStyle } from 'styled-components';
import coolFontPath from './font-file1.woff';
import cuteFontPath from './font-file2.woff';

const GlobalStyle = createGlobalStyle`
  @font-face {
    font-family: 'Cool Heading';
    src: url(${coolFontPath};
  }

  @font-face {
    font-family: 'Cute Heading';
    src: url(${cuteFontPath};
  }

  h1 {
    font-family: ${props => props.theme.heading};
  }

  span.subheading {
    font-family: ${props => props.theme.subHeading}
  }
`
export default GlobalStyle;

# App.js

import GlobalStyle from './GlobalStyle.js';
import theme from './theme.js';
import { ThemeProvider } from 'styled-components';

const App = () => {
  return (
  <ThemeProvider theme={theme}>
    <h1>I belong to the Cool Heading family</h1>
    <span className='subheading'>
      I belong to the Cute Heading family
    </span>
  </ThemeProvider>
  );
}

Summary

So there you have it! This was the exploration of three important concepts of the styled-library: Interpolation, GlobalStyling and ThemeProvider. Hope it was of use!

Folder Structure of a React Project

Alan Patrick — Fri, 22 Jul 2022 12:50:07 +0000

Intro

This is a guide for organizing your code when using React and styled-components, which is a CSS-IN-JS library, meaning you write the styling in a javascript file. There are other options for CSS solutions and their trade-offs, but that is topic for a different time.

Throughout the doing my projects, I felt the need of some structure for scaling my development. With a bit of luck and exploration, I stumbled upon the concepts of Directory-per-Component and Directory-per-view. There is a great resource talking about this structure at Survive.js.

Folder structure — How to organize the whole

The basic folder structure should follow something like this:

src/
- components/
- pages/
- assets/
- images/
- fonts/

The components folder is meant for any element that is reusable throughout the project. Headers, footers, styled buttons, etc. The pages folder is meant for... well, pages, like the ones links point to. The assets folder is in the source folder because adding them through javascript has some benefits, like bundling resources for fewer network requests (which speeds up the site). Check out the create-react-app documentation for a full explanation.

File structure — How to organize each piece

The basic file structure has two versions — state-full or state-less. This is an oversimplification (and probably a bad one), so I accept suggestions for replacements.

Stateless Elements

The state-less file structure is meant for elements not responsible for any logic within themselves, but still require styling. Examples would be simple containers, links, images and even buttons. These are components that would work in static pages.

These elements are often reusable and should be put under the components folder. They would require two files: the component.styled.js and index.js. They would be under the components folder. It would go something like:

src/
- components/
- CoolButton/
  - CoolButton.styled.js
  - index.js

WHY?

Using the index structure allows you to omit the the element being imported. This eliminates the ./components/CoolButton/CoolButton.component import path. Instead you get ./components/CoolButton with implied index. (More on this later.) Also, using the CoolButton.styled.js indicates (to you and others) that file is about styling.

What about using a separate css file instead? It does the same thing!

Styled-components eliminates the necessity to worry about class names. Less decisions equals more brain power! Check out decision-making fatigue.

What about losing the class selectors? How do you reference elements then?

In that case, you could just add the class names later, as a prop to the component. However, this will likely be unnecessary, due to useRef hooks and the Testing Library grabbing elements by their accessible features.

Small note about index exports

As explained, the index.js is a default entry point of node.js — the thing used by webpack to bundle your project.

An interesting tool for automating index creation is create-index. I haven't tested yet, but I will give it a try.

Stateful Elements

Stateful elements are likely to be pages (or views, or routes), where components are combined and logic is implemented.

The structure would be something like:

src/
- page/
- DataModal/
  - DataModal.styled.js
  - DataModal.js
  - index.js

While statefull elements closely resemble stateless ones in their file structure, there is an addition to the mix — the DataModal.js logic file. This is where you make use of the styled components created at DataModal.styled.js and give them behaviors. If the styled file creates a doll, the logic files gives the doll strings and turns it into a puppet.

How would those files look like?

With this structure, there is the basic pattern of Component.styled.js - index.js - Component.js. Of course, it won't be limited to that (where do tests fit in?!), but it is a nice start.

Component.styled.js: Here is where the styling comes into place. You will create the stateless components by using the styled-components tag functions like this:

#Component.styled.js
import styled from 'styled-components';

const ModalFrame = styled.div`
  background-color: lightblue;
  font-family: Lato, sans-serif;
  /* --- more styling -- */
`;
// As you can see, it looks just like css, but in js! :D
export { ModalFrame };

Component.js: Here you make use of stateless components to build stateful ones, like so:

#Component.js
import { ModalFrame } from './Component.styled.js';

const DataModal = () => {
  return <ModalFrame> {/*Some logic inside*/}</ModalFrame>;
};
export { DataModal };

index.js: It is where the default exporting actually happens. All you need to do is:

#index.js
export { DataModal as default } from './Component'; // './Component.styled' would also work

All what would be left is to import the component! Since index.js is the default entry point (as seen before), you can just import the directory directly (sorry, I had to):

#SomeView.js
import DataModal from './components/Datamodal'; // Look at that nice import!
// Rest of code

Summary

So, there you have it: a structured way of organizing your project, together with a tiny introduction to styled-components. It is what I will be using for a while now — though I have had my eyes on tailwind for a while. We'll see!

This is my first time writing about software development, so I'm accepting every feedback you guys may have!