
Quando iniciei na programação meu principal interesse era desenvolvimento de jogos. Mas esse nunca foi fácil, sempre limitado por ferramentas, algumas pagas, outras tão complicadas em suas funcionalidades que se tornavam inacessíveis. Mas ao longo dos anos essa situação tem mudado, com o lançamento de ferramentas gratuitas, acessíveis, e com o aumento de tutoriais na rede.

Mesmo com essa maior acessibilidade, ao longo dos últimos anos, nunca consegui escolher e permanecer em uma ferramenta, sempre tinha algo faltando, ou sobrando. Até nos meus anos mais produtivos usando Godot, a forma como certas partes funcionavam me confundiam, me atrasavam e amedrontavam com suas documentações complicadas e falta de tutoriais.

Depois, focando mais em frameworks em puro código, esses também nunca me satisfizeram, ou me deram o entusiasmo necessário pra cair de cabeça, estudar e realmente construir algo. Ou bati em uma parece que não sabia como escalar, como [naquele post] . Mas depois de muitas tentativas, e minha última antes de voltar pro Godot, acredito que encontrei algo que realmente me contenta e satisfaz com desenvolvimento de jogos.

Dito isso, gostaria de compartilhar um pouco da minha primeira experiência com Ruby e DragonRuby, minhas primeiras impressões sobre a linguagem, a engine, a comunidade e meu primeiro projeto por aqui.

## Ruby

Pra mim Ruby sempre foi o colega mais estranho e menos popular do Python, e depois de tantos anos programando em Python, Ruby começou a se tornar uma opção cada vez mais interessante. Depois de ouvir um pouco sobre a história do DHH e do Ruby on Rails (antes de todas as polêmicas recentes), Ruby se tornou uma pequena paixonite pra mim. Aquele conhecido distante que pensamos sobre nos dias mais atoa.

Em seguida li alguns capítulos de [Poingnant Guide to Ruby](https://www.amazon.com/Whys-Poignant-Guide-Lucky-Stiff/dp/1838039503), fiz alguns experimentos com Rails decidi dar uma olhada naquele framework Ruby, que apesar de ser pago, tinha opção para estudantes.

Alguns e-mail depois, eu estava com uma nova e poderosa ferramenta em mãos, mas eu não esperava que me daria tão bem com ela.

## DragonRuby

Primeiro, todo e qualquer projeto que começa com uma filosofia, você pode ter certeza que algo grande esta sendo construído. Assim como Ruby tem toda sua filosofia do porque as coisas são como são, DragonRuby segue o mesmo princípio e expande as ideias por trás de sua linguagem interna, trazendo todo um ideal de software e comunidade com o objetivo de ser sustentável e sobre pessoas (e eu sou uma pessoa). A todos que lerem esse texto, recomendo ler a página sobre [A Filosofia de DragonRuby](https://docs.dragonruby.org/#/misc/philosophy). Mas o ponto principal pra mim é:

> We will prioritize the removal of pain. The aesthetics of Ruby make it such a joy to work with, and we want to capture that within the engine.

E também:

> There is a programming idiom in software called “The Pit of Success”. The term normalizes upfront pain as a necessity/requirement in the hopes that the investment will yield dividends “when you become successful” or “when the code becomes more complicated”. This approach to development is strongly discouraged by us. It leads to over-architected and unnecessary code; creates barriers to rapid prototyping and shipping a game; and overwhelms beginners who are new to the engine or programming in general.

Olhando em retrospecto para minha jornada frustrada com desenvolvimento de jogos, acredito que esses (e outros aspectos) da filosofia de DragonRuby meus principais impedimentos em produzir algo.

### E daí?

Tendo em vista essa filosofia, o framework corta diversas etapas chatas e trabalhosas e transforma tudo em algo simples: arrays. Arrays por toda parte (acesso global incentivado), e por baixo dos panos tudo acontece.

> Acompanhando vários devs ao longo dos anos, vejo que todos eles convergem pra esse mesmo tipo de implementação: tenha um objeto gigante e genérico pra controlar o estado de tudo e passe ele por todo o seu jogo de forma a evitar passar argumento por argumento de um lugar pro outro

Todos esses arrays estão dentro de um objeto global chamado `args`, dentro dele temos:

- State: um objeto genérico onde injetamos todo o estado do jogo, como : `args.state.life = 0`
- Outputs: um array de outputs, incluindo audio, sprites, formas geográficas, textos e etc
- Inputs: um objeto que guarda e registra eventos de entrada, como teclado, mouse, etc.
- Events: Eventos extras que podem ocorrer com o dispositivo ou a janela, como mudança de orientação, tamanho da janela, etc.

E com isso, se constrói praticamente qualquer coisa (até onde eu explorei). Existem também diversos helpers pra auxiliar no desenvolvimento, como Grid, Layout, Easing etc. Além de centenas de exemplos de implementações de funcionalidades comuns em jogos dentro da documentação que você pode usar como exemplo. Não tem como pedir por mais.

Por fim, temos a comunidade do Discord, apesar de ser meio confuso o uso de cada canal (pelo menos pra mim), a comunidade é bem ativa, de tempos em tempos gosto de checar o _show-and-tell_ pra ver o que tem sido feito com a ferramenta, e até o próprio criador compartilha alguns projetos dele ali.

### Meus destaques pessoais

Toda a graça de DragonRuby é não ter que se preocupar com nada, nada mesmo. Você só faz o jogo, coloca as coisas no array e segue em frente, já é otimizado o bastante pra você poder fazer muita coisa errada até isso se tornar um problema (não me ocorreu ainda). Todos os conflitos são evitados, e o dinamismo de Ruby torna tudo possível e melhor de se trabalhar.

> It just works

Toda a experiência de desenvolvimento é fluida, sem impedimentos, sem configuração, sem dor de cabeça. Se tive uma ideia pro jogo eu crio um array, interajo com as entidades que preciso através da variável global e jogo na tela da forma mais simples. Depois, se for necessário, posso transformar os itens do array em uma classe, organizar em funções e abstrair apenas o necessário.

Em nenhum momento tenho que parar pra ler documentação, são apenas algoritmos, iteração e lógica básica, simplesmente incrível. Para prototipação nem se fala.

Talvez futuramente as coisas se tornem confusas de mais pra serem encontradas e entendidas, mas acredito que, se isso acontecer, será totalmente culpa minha por falta de organização própria. Espero escrever sobre isso em breve, pois meu projeto esta começando a tropeçar em si mesmo. Cabe ai aquele estudo sobre _patterns_ que estou devendo a alguns anos.

> Um extra sobre as funções agregadas de formatação de texto e lidar com números, tudo fica muito mais confortável, e olha que não conheço nem metade desses métodos ainda.

## Limitações

Meu único problema é com o LSP de Ruby, atualmente estou usando SolarGraph com RoboCup, mas ele não consegue dar conta do trabalho. Algo sempre esta quebrado, atualmente não posso minimizar uma função e salvar o arquivo, que ele maximiza de novo; os importes mesmo sendo encontrados recebem um aviso de "não encontrado"; a substituição global troca tudo incorretamente, não sabendo diferenciar entre objeto, hash, variável e o nome que eu pretendia mudar mesmo;

Por último, o _grep_, como toda a documentação é embutida no framework, sempre que faço um _grep_ ele me traz resultados de todos os exemplos da documentação, preciso achar uma forma de limitar essa busca a arquivos do meu jogo apenas.

Mas note, nenhum desses problemas tem a ver com o DragonRuby, mas sim com meu ambiente de desenvolvimento.

## Meus Experimentos

Falando um pouco sobre meus experimentos no framework: estou tendo diversas ideias de jogos nos últimos meses, então prototipar no DragonRuby (o forte do framework) foi o que mais fiz. Primeiro fiz apenas um controle de câmera com zoom, nada de mais; Depois comecei um protótipo de um jogo de barco que eu tinha imaginado. Segui com esse protótipo por aproximadamente 1 mês. Mas como é um estilo de jogo que eu não entendo muito, estava ficando sem ideias e o desenvolvimento se complicou um pouco, acabei deixando o projeto de lado. Decidi aprender a fazer jogo recriando algumas funcionalidades de um dos meus jogos favoritos: [Nuclear Throne](https://store.steampowered.com/app/242680/Nuclear_Throne/).

E foi assim que caí na espiral do projeto pequeno que se torna um projeto grande, o medo e destino de todo desenvolvedor de jogos iniciante. Sim, ja passei por isso diversas vezes no passado, com diversos projetos diferentes, mas dessa vez foi curioso. Eu comecei definindo que não iria me perder trabalhando em coisas fora do escopo de funcionalidade, ou seja, nada de melhoria visual, nada de efeitos que demoram horas pra chegar no ponto certo, nada de se perder em algo que não importa pra um projeto simples.

Semanas depois e eu estou planejando qual o próximo game juice devo adicionar no jogo. E a sina se repete.

Eu estava planejando eventualmente fazer conteúdo sobre desenvolvimento de jogo, mais pro fim do ano. Mas acabei começando a fazer algumas lives desenvolvendo esse projeto, e daí comecei a fazer alguns clips e jogar em algumas plataformas. Parei com as lives pois estava sendo super estressante e demandando muita energia. Decidi fazer apenas 1 vídeo, pois estava muito animado. Depois de publicado esse video acabei gostando do engajamento que estava recebendo no TikTok, decidi continuar fazendo alguns vídeos por semana documentando o processo.

Apesar de odiar o formato, por ser muito limitado, acabei vendo a plataforma como uma forma de divulgar o jogo se eventualmente fosse virar um projeto real. Então decidi transformar esse projetinho no meu primeiro lançamento, mas coloquei uma data limite: tenho que lança-lo esse ano. Independente do que ele se tornar, ele é meu primeiro jogo e tem que ser lançado em 1 ano. Não é uma ideia nova, então não promete nada, mas quero ter um sandbox onde posso adicionar qualquer mecânica que acho interessante em um jogo num estilo que acho interessante. Sempre quis ter um projeto pra brincar assim, e acho que é num top-down-shooter que me encontrei.

## Conclusão

De qualquer forma, espero continuar postando meus vídeos sobre o desenvolvimento desse jogo tanto no [TikTok](https://www.tiktok.com/@renatogamedev) quanto no [Youtube](https://www.youtube.com/@vodsrenatogamedev). Vou tentar documentar um pouco do processo aqui também, entrando em mais detalhes, planos e ideias. Tem muito o que fazer e trabalhar nos próximos meses.

Sobre DragonRuby, acho que é a minha ferramenta de escolha pra próximos projetos, apesar das limitações de não ter shaders e outros tipos de manipulação de imagem e sprites. Escolho esse framework pois me possibilita sentar e adicionar algo no jogo em 1 hora. Me sinto produtivo, me sinto fluindo com as ideias. Recomendo a todo interessado experimentar.

Espero trazer Atualizações sobre o jogo aqui em breve, comentar um pouco sobre os planos e o processo. Até mais!


Minha experiência com DragonRuby


A ideia desse texto começou comigo reclamando de alguns problemas (totalmente skill issues) que tive com a linguagem Odin e seus ponteiros e procedimentos, depois, tentando recriar o problema original que tive em uma versão reduzida e apresentável do código, acabei resolvendo o problema. Então o texto se tornou sobre como organizar a solução de forma que ela ficasse mais bem estruturada, com um design de software melhor de trabalhar e de expandir e alterar com o tempo.

Porém, jogos são complexos, e achar essa solução mais limpa, ou até mesmo testar outras soluções já seria um desafio extra. Dessa forma, o texto virou um incentivo pra eu estudar sobre Data-Oriented-Programming (algo que estou adiando a quase 1 ano pra estudar) e _composition_, além de outros _patterns_ que poderiam resolver o problema.

Durante o começo desse estudo, encontrei um dos posts mais interessantes que já vi na internet, onde o autor Eric Leppert trazia um exemplo simples de regra de negócio e tentava fazer essa regra ser obedecida através apenas das definições de OOP do C#.

> Ótima leitura [Wizards and Warriors](https://ericlippert.com/2015/04/27/wizards-and-warriors-part-one/) do Eric Leppert

Diante dessa leitura pensei que talvez, esse post poderia ser apenas uma demonstração, assim como a do Eric, sobre soluções problemáticas para uma regra que, inicialmente, é simples.

---

A verdade é que software design é uma das coisas que mais me encantam, sempre tive discussões intermináveis na minha cabeça sobre como eu implementaria X sistema pra ser escalável e expandível, mas nunca consegui colocar em prática essas discussões. E o Eric coloca de uma forma muito interessante. Claro que no caso dele ele já sabe a solução, e eu ainda não. Mas acho que vai ser uma boa iniciativa pra buscar esses designs melhores e soluções interessantes, além de me direcionar para concretizar as minhas ideias, sistemas e estudos.

Então aqui veremos uma das minhas primeiras tentativas implementando um sistema com uma mentalidade mais voltada para Data-Oriented-Design e Composition, onde eu falho miseravelmente, mostrando o quanto ainda tenho que aprender e melhorar.

Veremos também alguns comentários que tentam refutar as minhas próprias explicações para o que eu acho e fiz quando escrevi aquele código. Acredito que essa abordagem de aprendizado seja boa:

1. você enfrenta um problema;
2. tenta lidar com ele com o que você sabe e se frustra tentando; (este post)
3. estuda sobre possíveis soluções tendo seu problema em mente durante;
4. volta pra solucionar o problema com o conteúdo aprendido; (o próximo post)
5. se frustra de novo.
6. resolve o problema

## O Problema

Estava testando algumas abordagens diferentes do que eu geralmente costumo fazer, testando o que eu entendia sobre _composition_ e _Data-Oriented-Programming_, abordagens que tenho ouvido muito falar no meio do desenvolvimento de jogos, mas que nunca experimentei na prática.

Diante disso comecei um projeto onde tentaria implementar alguns sistemas usando o que eu estava entendendo sobre _composition_.

> Esse exemplo em questão foi desenvolvido em Odin, usando Raylib para renderização

## Estrutura Base

O que temos aqui é um sistema de _Colliders_ e _Entities_, onde a ideia é que entidades tenham _colliders_, porém não como propriedades diretas delas, evitando acoplamento.

> Na verdade essa ideia se originou de um vídeo que eu vi de otimização de memória, que me deixou super interessado em aprender sobre Data-Oriented, porém fui implementar estudos mais aprofundados sobre a teoria. O vídeo: [Intro to Data Oriented Design for Games](https://www.youtube.com/@nicbarkeragain)

A ideia então é ter sistemas, que são _arrays_ de entidades de um mesmo tipo e são responsáveis por gerenciar essas entidades e disponibilizar métodos que agem sobre os dados desse sistema. Aqui temos um `CollisionSystem` que tem uma lista de _Colliders_:

```odin
Collider :: struct {
    position: Vec2,
    radius: f32,
}

CollisionSystem :: struct {
    colliders:  [dynamic]Collider,
}

update_collisions :: proc(sys: ^CollisionSystem) {
	for i in 0 ..< len(sys.colliders) {
		for j in i + 1 ..< len(sys.colliders) {
			a := &sys.colliders[i]
			b := &sys.colliders[j]
			r := a.radius + b.radius
			if distance_squared(a.position, b.position) <= r * r {
				//colided
			}
		}
	}
}

add_collider :: proc(sys: ^CollisionSystem, collider: Collider) -> ^Collider {
	append(&sys.colliders, collider)
    return &sys.colliders[len(sys.colliders) - 1]
}

```

Também temos uma estrutura `Entity` onde guardamos os dados gerais e é o centro do nosso design, suas propriedades podem eventualmente serem convertidas para sistemas à parte quando necessário.

```odin
Entity :: struct {
    name: string,
    position: Vec2,
    collider: ^Collider
    color: rl.Color,
}
```

## A Primeira implementação - O problema do ponteiro

A ideia inicial era que a entidade tivesse um ponteiro para seu _Collider_ de forma que ela pudesse muda-lo quando precisasse, como fazer o _collider_ seguir a posição dela. A primeira implementação ficou mais ou menos assim:

```odin
player_collider := Collider {
	position = player.position,
	radius   = 30,
}

enemy_collider := Collider {
	position = enemy.position,
	radius   = 30,
}

player.collider = add_collider(&collision_system, player_collider)
enemy.collider = add_collider(&collision_system, enemy_collider)

//Durante o update
player.collider.position = player.position
enemy.collider.position = player.position

update_collisions(&collision_system)
```

Esse exemplo funciona bem até adicionarmos mais _colliders_ na lista, quando eventualmente o _garbage collector_ limpa todos os ponteiros existente (ou algo do tipo) e o `player.collider` passa a ser um ponteiro invalido. Então quando ele tenta atualizar seu próprio _collider_, boom!

```
post(46201,0x16bf23000) malloc: Heap corruption detected, free list is damaged a
t 0x600000f8bf90

*** Incorrect guard value: 0
post(46201,0x16bf23000) malloc: *** set a breakpoint in malloc_error_break to de bug
```

Logo, ter um ponteiro na entidade para o seu _collider_ não funciona, pelo menos não dessa forma. Talvez um `raw pointer` seria o correto a se utilizar aqui, mas isso leva a outros problemas e dificuldades também.

## A Solução para os Ponteiros Perdidos

Dessa forma, como não podemos apontar diretamente para o nosso _collider_ temos que achar outra forma de acessar esse _collider_. A solução mais óbvia é armazenar, na entidade, o índice do *collider* correspondente da lista do `CollisionSystem`.

Assim temos uma forma fácil de acessar o elemento em questão que não depende de funcionalidades internas da linguagem que não temos controle. A única desvantagens é se tivermos algum tipo de ordenação na lista, e como isso não existe ainda, não temos com o que se preocupar.

```odin
Entity :: struct {
    name: string,
    position: Vec2,
    color: rl.Color,
    collider_index: int,
}

add_collider :: proc(sys: ^CollisionSystem, collider: Collider) -> int {
	append(&sys.colliders, collider)
	return len(sys.colliders) - 1
}

// cria colliders...

player.collider_index = add_collider(&collision_system, player_collider);
enemy.collider_index  = add_collider(&collision_system, enemy_collider);


// [Durante o update]
// Atualizar posição do collider com base na entidade
collision_system.colliders[player.collider_index].position = player.position;
collision_system.colliders[enemy.collider_index].position = enemy.position;

update_collisions(&collision_system)

```

Essa implementação já resolve o nosso problema de perda de ponteiros, apesar de limitar a nossa capacidade de manusear a lista de _colliders_. Porém, como o sistema de colisão não sabe nada sobre a entidade, não temos como manipular ela durante um callback de `on_collide()` por exemplo. Como poderíamos, por exemplo, empurrar o nosso jogador para trás quando ele encostasse em um inimigo?

O que poderia ser feito é inverter essa lógica: O colisor sabe da entidade, e a entidade é dependente do colisor, mas isso só levaria ao mesmo problema, porém invertido. E é ai que os problemas da minha ignorância sobre esses padrões começam a aparecer mais.

## Quem Aponta para Um, Aponta para Dois

Pedindo uma ajudinha pra IAs Generativas, foi indicado a seguinte solução: a adição de um `raw-pointer` no meu _collider_ que aponta de volta para a entidade.

> Essa solução me da arrepios sempre que penso sobre ela. Mostrando como LLMs podem te direcionar para a pior solução de todas.

```odin
OnCollideProc :: proc(ctx: rawptr, other: ^Collider)

Collider :: struct {
	position: Vec2,
	radius:   f32,
	ctx: rawptr,
	on_collide: OnCollideProc,
}
```

Porém, isso leva a necessidade de alguns _casts_, o que não me parece muito interessante a longo prazo:

```odin
player_collider := Collider {
	position = player.position,
	radius   = 30,
	ctx = rawptr(&player),
	on_collide = proc(ctx: rawptr, other: ^Collider) {
		entity := cast(^Entity)ctx; //cast :(
		entity.color = rl.YELLOW;
		fmt.println("{} colidiu com algo!", entity.name);
	},
}
```

## Isso funciona (?)

Claro, essa solução "funciona", mas nem sempre funcionar é realmente _funcionar_! Fazer um `is_odd` usando a negação da função `is_even` do pacote `is_even` em javascript também funciona, mas não deveria ser aceito como uma solução valida, assim como essa também não deveria.

Outro detalhe: essa solução "funciona" para o player, mas não para os _enemies_, o `on_collide` entre os inimigos simplesmente não funciona, pois estamos nos referindo a uma cópia do inimigo e não ao inimigo mesmo. E transformar a lista de inimigos em uma lista de ponteiros para inimigos não da certo (eu testei).

---

A questão aqui é: o quão granular deve ser a composição de elementos? O certo seria ter um _collider resolver_ que seria responsável por lidar com o resultado das colisões, e este cara saberia da entidade e do colisor? Talvez ninguém deveria saber sobre ninguém e um terceiro deveria cuidar de tudo?

Pesquisando um pouco sobre essa questão vi algumas sugestões de que tudo deveria ser vetores/arrays de _structs_ (inimigos, entidades, posições, acelerações) de forma bem granular, e a entidade deveria guardar o índice para cada um desses componentes. Mas isso ainda não resolver diretamente a influência que a posição da entidade tem no _collider_ vice-e-versa.

Diante disso, decidi parar e estudar as soluções existentes, e buscar algo que fosse simples, funcionasse e fosse de fácil utilização/implementação.

## Conclusão

A verdade é que não vale a pena tentar reinventar a roda sendo que existem soluções que já foram encontradas, debatidas, testadas e utilizadas no mundo real. Se frustrar tentando é só um exercício pra colocar a mão na massa e se interessar e bater de cara com o problema.

Dito isso, vou estudar algumas soluções mais simples que são implementáveis aqui, nada muito distante e complexo como um ECS (Entity-Component-System) por enquanto. Vou tentar trazer algumas dessas soluções pra cá e comentar sobre o que acho delas. Mas me anima imaginar o quão praticas elas podem ser.


Minha primeira tentativa com Data-Oriented em Game-Dev


Olá a todos! Faz tempo que não escrevo por aqui, pois estive ocupado e não programando muito. Mas prometo que voltarei a trabalhar com joguinhos e coisas interessantes para que eu possa movimentar mais esse site.

Dessa vez estou trazendo um novo projeto, que comecei apenas como uma forma de experimentar TUIs (Terminal User Interfaces) e ter alguma coisa simples pra mexer de vez em quando sem ter que abrir 5 programas diferentes (Ah! o desenvolvimento mobile).

# A ideia

A ideia inicial do projeto apareceu pela necessidade de ter uma junção de:

1. Obsidian: criar, editar e organizar notas com facilidade
2. Zotero: Ler arquivos PDF e destacar trechos
3. Inverter cores de um PDF pra não perder a visão (não devíamos ter mantido no computador o padrão da cor real do papel, não foi uma boa ideia)

Seria meio que um sistema para auxiliar na condução de pesquisas científicas, principalmente de revisão da literatura, junto com um diário de pesquisa e organização de tarefas.

Sim, um escopo gigantesco não é mesmo?!

Nessa mesma época eu havia começado a estudar Go, e fiquei sabendo de uma ótima ferramenta para construir TUIs, o [Charm\_](https://charm.sh). Na verdade o Charm é uma coleção de bibliotecas com esse propósito. Sabendo da existência dessa ferramenta fiquei com uma pulga atrás da orelha querendo construir algo com ela. Depois de tantos anos mexendo com CSS puro, interfaces gráficas de Flutter baseadas em OOP, o que faltava experimentar eram interfaces de terminal. (Não me faça lembrar de quando montei UIs em Java)

Enfim, acabei reduzindo o escopo do projeto a apenas um Obsidian de terminal, que eu pudesse pelo menos ler o conteúdo de um PDF. Sendo no terminal, não seria voltado para o usuário final, mas para os estranhos que curtem essas paradas. Ainda assim, acho a ideia de um Zotero modernizado boa, e não descartarei ela por completo (realmente odeio coisas feitas em Java, e se o Zotero é feito em java, ele deve morrer).

Eventualmente, um dia qualquer sozinho numa das minhas hambúrguerias favoritas, me bateu a inspiração pra começar esse projeto, aquele tipo de inspiração que começa por: "quer saber, eu vou fazer isso agora, e semana que vem estará feito". Falhei miseravelmente.

# A primeira tentativa

Minha primeira tentativa foi muito mal sucedida, confesso. Após abrir a pasta e listar por todos os arquivos, através das funções oferecidas pelo pacote `os` da linguagem go, me vi com uma lista única de arquivos, sem a possibilidade de ter arquivos dentro de pastas, e nem pastas dentro de pastas.

Óbvio, o sistema de arquivos são armazenados em árvore, então precisaria reconstruir essa arvore de arquivos enquanto itero sobre os arquivos do diretório selecionado (no caso o diretório do próprio projeto). Mas, pra alguém que tinha estudado árvore mais de 1 ano atrás, sem nunca ter implementado nada sobre elas, a ideia ainda estava confusa.

Usando a abstração de árvore fornecida pelo Charm e muito ChatGPT, a única coisa que consegui foi uma confusão total e alguns código recursivos que não faziam sentido algum pra mim.

Nesse momento, meu pedido havia chegado e eu tinha prioridades maiores na mesa.

# Reencontro de um problema

Como havia comentado no começo desse post, ainda estou ocupado finalizando alguns detalhes do meu bacharelado, mas ao mesmo tempo, não posso deixar de programar 100%, faz parte da minha natureza.

Por isso, estava procurando algum projeto para trabalhar que não exigisse: anos de estudo de algum tópico extremamente específico (ffmpeg); nem a complexidade de um formato de arquivos de décadas de idade (PDFs); muito menos algo que fizesse meu cérebro queimar de tanta novidade e complexidade (Computação gráfica). Ao mesmo tempo procurava algum projeto que não exigisse programas ou procedimentos secundários, como abrir um servidor; abrir emuladores; game engine; dezenas de abas com documentação e perguntas do StackOverflow.

Precisava de algo direto e que eu conhecesse minimamente, pra buscar aquela sensação de realização que só a programação, a criação de algo do absoluto (mais ou menos) zero, pode trazer.

Essas ideias circularam na minha cabeça quando pensava sobre o que programar. Quando me lembrei daquele maldito problema, de arvore de arquivos, que havia me derrotado meses.

Olhando em retrospecto parecia um problema simples: é uma lista de arquivos, mas ao encontrar uma pasta, cria uma nova lista e recomeça o processo do 0. Se fizer de forma recursiva e direta fica mais fácil do que parece.

> Cabe lembrar que, entre esses meses que se passaram, trabalhei em um dos mais apressados e complicados projetos que já tive na carreira. Onde aprendi sobre a importância de ser eficaz, direto e simples. Quando vi o problema pós-projeto, parecia muito mais simples do que quando encontrei-o pela primeira vez.

# Uma segunda olhada

Revisitando o projeto me deparei com algo que não reconhecia como minha criação, mas de fato era um frankenstein: junção de códigos da documentação do Charm, códigos gerados por LLVMs diferentes, e algumas suturas entre eles de minha autoria.

Fiquei em dúvida: deveria apagar tudo e começar do zero? Ou deveria tentar salvar o que prestava (não muito). Confesso que cheguei a apagar o projeto, mas, delicadamente, recuperei-o da lixeira. Com fé de que havia algo de bom restante naquelas linhas confusas.

Infelizmente não tenho como mostrar-lhes como estes códigos se pareciam (e acho que nenhum de vocês suportaria), pois na época não havia criado um repositório para o projeto, e não compartilhei com ninguém, pois o mundo era um lugar melhor sem aquelas linhas.

Apaguei maior parte do código, principalmente referente a geração da arvore e iteração sobre os arquivos. Naquela hora, decidir que iria implementar a estrura de árvore sem nenhuma abstração ou auxílio de terceiros, iria parar e pensar sobre como resolver aquele problema. E foi uma das melhores ideias que tive.

# A solução

A melhor forma de solucionar qualquer problema é simplesmente descontruí-lo até um ponto que se saiba resolver. Se uma árvore esta parecendo um problema complexo, simplifique-a para algo mais simples: uma árvore nada mais é do que um elemento que tem vários filhos (uma lista), sendo que esses filhos podem ter outros filhos, logo, uma árvore é uma lista com listas dentro, De forma que vire um looping possivelmente infinito.

Falando assim parece até idiota ter um semestre inteiro pra estudar grafos (brincadeira, a complexidade vem em outra parte dos grafos).

Então a solução é simples: passar por todos os arquivos adicionando eles como filhos de um nó pai, quando achar uma pasta, fazer o mesmo para ela como se ela fosse o nó pai, quando chegar ao fim, insere todos os nós achados no nó atual.

Se pensar de forma recursiva fica ainda mais fácil de implementar. E explicando assim, o Renato do passado só parece ainda mais idiota por não ter solucionado isso antes do lanche ficar pronto.

# O código

Para o código criei um tipo chamado `Node` para representar cada um dos elementos da árvore, adicionei todas as informações que poderiam ser úteis para o resto do meu programa, como o caminho para o arquivo (`path`); se ele é ou não uma pasta (`isDir`) e também um ponteiro para o próprio pai (`Parent`), que pode ser usado para caminhar pela árvore de forma mais fácil e fazer algumas checagens extras caso necessário.

Além disso, tem a função principal: `walkNodeAndGetChildren`, que é bem auto-explicativa, ela passa por todos os arquivos uma pasta de um diretório x ( recebido como argumento em `dir`), cria e adiciona todos os arquivos como filhos de um nó, também passado por argumento (`node`). Caso o filho atual seja uma pasta, chamamos (`walkNodeAndGetChildren`) novamente para esta pasta.

Segue o código em Go:

```go
type Node struct {
	Name     string
	Path     string
	IsDir    bool
	IsOpen   bool
	Parent   *Node
	Children []*Node
}

func main(){
	baseDir := "."
	root := &Node{Name: baseDir, IsDir: true, Path: "."}
	root.Children = walkNodeAndGetChildren(".", root)
}

func walkNodeAndGetChildren(dir string, node *Node) []*Node {
	files, _ := os.ReadDir(dir)
	for _, file := range files {
		path := fmt.Sprintf("%s/%s", dir, file.Name())

		walkedNode := &Node{
			Name:   file.Name(),
			Path:   path,
			Parent: node,
			IsDir:  file.IsDir(),
			IsOpen: false,
		}

		if walkedNode.IsDir {
			walkedNode.Children = walkNodeAndGetChildren(path, walkedNode)
		}

		node.AddChild(walkedNode)
	}
	return node.Children
}
```

Nota-se a concatenação do diretório atual com o nome do arquivo atual na primeira linha do `for`. É uma operação simples que resolve dois problemas: criar o caminho do nó que estamos passando atualmente e conseguir o caminho para a próxima chamada da função caso o nó seja uma pasta. É um detalhe bobo, mas eu achei interessante como foi fácil fazer tudo de uma só vez depois que já tinha a lógica.

# O charme

Mas é claro que essa é só uma parte da solução e do que vim aqui apresentar-lhes. Pois o verdadeiro charme é na visualização disso tudo usando a biblioteca `Charm`.

Primeiro, para organizar tudo centralizei esse componente em um novo arquivo e estrutura chamada `FileTree`, que contem algumas informações, além de diversas funções que auxiliarão a percorrer o nossa árvore criada com tanto carinho. Segue algumas informações iniciais sobre essa estrutura:

```go
type FileTree struct {
	InitialNode  *tree.Node
	hoveringNode *tree.Node
	SelectedNode *tree.Node
}

func (f FileTree) Init() FileTree {
	baseDir := "."
	root := &tree.Node{Name: baseDir, IsDir: true, Path: "."}
	root.Children = walkNodeAndGetChildren(".", root)

	return FileTree{InitialNode: root, hoveringNode: root.Children[0]}
}
```

Nota-se, primeiro, os campos existentes nessa estrutura: `InitialNode`, que indica o pai de todos os arquivos, o nó primordial; `hoveringNode`, como o objetivo é fazer uma visualização, é importante saber sobre qual arquivo o cursor esta atualmente, guardamos ele aqui; `SelectedNode`, esse ainda esta sendo pensado, mas ele guarda o último nó selecionado para visualização, não tem tanta importância ainda.

Para navegar dentro da árvore de arquivos e alterar o `hoveringNode` corretamente, escrevi algumas funções bem interessantes para pegar o nó acima e abaixo do nó atual dependendo do contexto. A implementação atual não é perfeita (já achei alguns bugs), mas é muito interessante:

> As funções ainda estão atribuídas a estrutura `Node`, uma péssima escolha de design, mas facilmente corrigível, após finalizar esse texto ajusto esses detalhes

```go
// Navegar para cima
func (n *Node) GetNodeAbove() *Node {
	currentIndex := n.Parent.GetChildIndex(n)
	if currentIndex == 0 { // é o primeiro arquivo de uma pasta?
		// Se não tem ninguem em cima, ou é o primordial, não da pra subir
		if n.Parent == nil || n.Parent.Path == "." {
			return nil
		}
		return n.Parent
	}
	//Se esta subindo, e não é o primeiro, o próximo nó é o irmão de cima
	next := n.Parent.Children[currentIndex-1]
	// Essa parte esta dando problema, não entraremos aqui por agora
	if next.IsDir && next.IsOpen {
		return next.GetDeepestChildOpen()
	}
	return next
}
```

Começando pela navegação para cima: que código simples, apenas alguns comentários e já é possível entende-lo por completo. O primeiro passo é entender quem é o node que estamos atualmente (`n`). Ele é o primeiro nó? é o último? é uma pasta? Sabendo isso podemos tomar uma decisão sobre onde o cursor vai. Se for o primeiro nó de uma pasta, devemos subir para o pai dela (se ele existir). Se não subimos para seu irmão de cima, e se ele for uma pasta, vamos para o filho da pasta mais profunda aberta. Tandam! temos a navegação pra cima.

> A parte da pasta mais profunda ainda esta dando alguns problemas, mas espero conserta-los depois que tiver uma ordenação correta dos nós. Mas o concerto é basicamente seleciona o arquivo mais profundo, se ele for uma pasta e tiver aberto, selecionar o arquivo mais profundo dessa pasta, e assim por diante.

---

A navegação para baixo:

```go
func (n *Node) GetNodeBellow(isFirstInteration bool) *Node {
	if n.IsDir && n.IsOpen && len(n.Children) != 0 && isFirstInteration {
		return n.Children[0]
	}
	currentIndex := n.Parent.GetChildIndex(n)
	if n != n.Parent.LastChild() {
		return n.Parent.Children[currentIndex+1]
	}

	//Evitando mover caso seja o último node
	if n.Parent == nil || n.Parent.Path == "." {
		return nil
	}
	return n.Parent.GetNodeBellow(false)
}
```

Acredito que existam formas melhores de fazer ambas as operações que mostrei, mas essa é a forma que eu achei e isso que importa (até o momento que deixar de funcionar).

# O resultado

Depois de alguns ajustes de estilização do Charm (lipgloss na verdade, mas faz parte do Charm) o resultado me agradou muito, foi um dos momentos mais gratificantes que tive com programação nos últimos meses (estou a um tempo sem programar nada). Ver a minha própria arvore de arquivos feita praticamente do 0 com concatenação de strings foi como ver meu primeiro site HTML-CSS quando comecei a programar 5 anos atrás.

É incrível pensar que, mesmo depois desses anos, ainda é possível encontrar esse mesmo sentimento de gratificação, como se fosse a primeira vez, apenas fazendo coisas levemente diferentes.

Segue o resultado:

![arvore resultado](arvore-resultado.gif)
Ainda tem vários problemas com a abordagem atual, como o espaçamento que fica entre uma pasta com arquivos e os outros arquivos do pai dela (ver no gif, pois é difícil explicar em palavras). Acredito que esteja havendo alguma concatenação de um `\n` extra em algum lugar, mas não consegui identificar onde exatamente ainda.

Existe algum caso onde o resultado de `GetNodeBellow` resulta em um `nil` fazendo com que o programa inteiro quebre. Ainda preciso investigar melhor, mas acredito que seja por uma falta de "esperar" algo carregar, não tenho certeza.

Sobre o resultado do programa em sí, também tem seus problemas. O conteúdo do arquivo aberto esta sendo mostrado utilizando um viewport do bubbles (outro pacote do Charm). Contudo, esse conteúdo esta bem estranho, acredito que eu tenha cometido algum erro tentando seguir o exemplo da documentação. Preciso rescreve-lo para ver se concerto.

Além disso estou tentnao mostrar a arvore de arquivos e o conteúdo do arquivo aberto lado a lado, porém, o método `JoinHorizontal` simplesmente não faz a junção horizontal permanente, mas sim apenas estática e momentânea. Fazendo com que a arquivo de arquivos seja sobrescrita pelo conteúdo do arquivo aberto:

![bug-final](bug-final.gif)

Os outros problemas são mais relacionados a TUI do Charm, e espero que a solução seja simples.

Volto em breve com a continuação desse projeto se tiver resultados com esses casos.

Outra questão que precisa ser melhorada é a abertura de arquivos maiores, eles simplesmente quebram totalmente o programa tentando guardar o arquivo inteiro como uma string. É uma otimização interessante de realizar e provavelmente da um post por si só.

Enfim, vou ficando por aqui, até a próxima.


Arvore de arquitos em uma TUI


Num fim de tarde qualquer, buscando programar algo, como é de minha natureza, decidi me aventurar em um desafio do [Advent of Code](https://adventofcode.com/), um site clássico repleto de problemas de lógica e programação.

Com vontade de experimentar uma nova linguagem, decidi começar com o [Zig](https://ziglang.org/). Após algumas pesquisas no Google, e cerca de vinte linhas de código, tudo que consegui produzir foi um modesto **5** (o arquivo txt que deveria ser aberto não começava com 5). Admito que são Skill-Issues da minha parte; se tentasse novamente, provavelmente conseguiria (pelo menos abrir o arquivo).

Minha segunda tentativa foi com [Lua](https://www.lua.org/). Já havia brincado um pouco com `tables` e até fiz um círculo seguir meu mouse no [Love2D](https://love2d.org/), então imaginei que tinha experiência suficiente para abrir um arquivo e escrever alguns if-statements.

E lá fui eu.

# A Primeira Parte do Desafio

O desafio em questão é o primeiro dia do [Advent of Code 2023](https://adventofcode.com/2023/day/1). Em resumo: temos um arquivo `.txt` com várias linhas, cada uma contendo uma sequência aleatória de caracteres e alguns **números**. O objetivo é concatenar o primeiro e o último número encontrado em cada linha, somar todas as concatenações e obter o resultado final.

A solução é bastante simples: percorrer cada linha, salvar todos os caracteres que forem inteiros, concatenar o primeiro e o último número da lista e somar ao resultado final.

Por exemplo, dada a linha abaixo, a resposta seria **15**:

```
a1b2c3d4e5f
```

Agora chegamos à segunda parte do desafio, que, embora também simples, me deixou um pouco perdido (ou será que "perdido" não é bem a palavra certa? Skill-issues).

# A Segunda Parte do Desafio

A segunda parte do desafio adiciona uma nova camada de complexidade: além dos números, agora também encontramos números escritos por extenso (não na forma numérica, mas textual), o que nos apresenta outro desafio, mas um que ainda pode ser enfrentado facilmente.

Para resolver isso, percorremos cada linha, buscamos os números e suas representações escritas (`one`, `two`, `three` e assim por diante), e os armazenamos em um HashMap (no final tudo é table) contendo a posição em que foram encontrados e seu valor. Em seguida, ordenamos o HashMap pelas chaves, pegamos a primeira e a última chave e pronto! Temos a resposta somando essas concatenações.

> Claro que existem maneiras mais eficientes de resolver esse problema, mas às vezes é bom tentar resolver o problema primeiro e depois buscar a melhor solução.

Vamos dar uma olhada em como abordei inicialmente essa segunda parte. Para evitar confusão sobre qual parte do código faz o quê, vou começar com o código de filtragem dos números:

```lua
for i = 1, string.len(line) do
  local char = string.sub(line, i, i)
  local inNumber = tonumber(char)
  if (inNumber) then
    currentResult[i] = inNumber
  end
end
```

Também criei uma tabela (seria um HashMap, mas em Lua tudo são tabelas) para facilitar a conversão dos valores:

```lua
NUMBERS_AS_LETTERS = {
  ["one"] = 1,
  ["two"] = 2,
  ["three"] = 3,
  ["four"] = 4,
  ["five"] = 5,
  ["six"] = 6,
  ["seven"] = 7,
  ["eight"] = 8,
  ["nine"] = 9,
};
```

# Continuando com o Post

Eu estava escrevendo este texto quando o NeoVim apagou meu arquivo original, que continha o código em que estava trabalhando, e o substituiu por uma versão antiga do exercício, onde resolvia apenas a primeira parte do problema.

Por isso, comecei a resolver a segunda parte novamente. Então, me deparei com alguns problemas:

- Meu Bubble Sort não estava mais funcionando.
- A seleção de números que mostrei anteriormente também não estava funcionando.

Parecia que dois dias atrás eu era um gênio em Lua, e agora não era mais. Então, refiz os códigos da forma mais simples possível, pois nada funcionava:

```lua
for i = 1, #line do
  local char = string.sub(line, i, i)
  local inNumber = tonumber(char)
  if (inNumber) then
    currentResult[i] = inNumber
    if (i < minFound) then minFound = i end
    if (i > maxFound) then maxFound = i end
  end
end
```

Minha primeira tentativa de identificar os números escritos por extenso foi usando o método `string.find()` durante uma iteração na minha tabela de números escritos (`NUMBERS_AS_LETTERS`):

```lua
  for key, value in pairs(NUMBERS_AS_LETTERS) do
    local allFound = liner.find_all(string.lower(line), key)
    for _, val in ipairs(allFound) do
      if (val) then
        currentResult[val] = value
        if (val < minFound) then minFound = val end
        if (val > maxFound) then maxFound = val end
      end
    end
  end
```

Até aí tudo bem. Usei esse código a seguir para conectar o valor primeiro e último número, converte-lo em inteiro e somando-o ao total:

```lua
local fstring = string.format("%s%s", currentResult[minFound], currentResult[maxFound])
local finalLineNumber = tonumber(fstring)
totalSum = totalSum + finalLineNumber
```

No entanto, uma das linhas do desafio era esta: `6ftv`, onde só há um número. Portanto, temos que lidar com esse tipo de caso específico. Verificamos o tamanho da lista do nosso resultado final e, se ela tiver apenas um elemento, não fazemos a concatenação, usamos apenas esse elemento. [⚠️WARNING⚠️]

# O Problema com `len` e `string.find`

Então, alguns problemas começaram a surgir. Existem duas maneiras de acessar o tamanho de uma tabela: `table.getn(table)` ou `#table`. De acordo com a documentação, ambas são equivalentes. No entanto, quando executei a primeira opção, recebi um erro dizendo que estava tentando executar em uma variável `nil` (que não era `nil`). Já a segunda não me deu erro, mas retornou o tamanho incorreto da tabela.

Pode-se argumentar que estava usando as tabelas de uma maneira não muito convencional (com números como chaves e como valores também), mas uma função simples como essa deveria funcionar corretamente.

Tentei mover a definição da minha tabela `currentResult` para fora do loop, tentei adicionar múltiplos resets dessa variável para garantir que estava tudo certo, mas nada funcionou.

Aqui está o código em questão e alguns dos meus outputs:

```lua
for line in io.lines("./input.txt") do
  local maxFound = -1
  local minFound = 10000
  -- ----- NUMBERS ----
  for i = 1, string.len(line) do
    local char = string.sub(line, i, i)
    local inNumber = tonumber(char)
    if (inNumber) then
      currentResult[(i)] = inNumber
      if (i < minFound) then minFound = i end
      if (i > maxFound) then maxFound = i end
    end
  end

  -- ----- WORDS ----
  for key, value in pairs(NUMBERS_AS_LETTERS) do
    local indexFound = string.find(line, key)
    if (indexFound) then
      currentResult[(indexFound)] = value
      if (indexFound < minFound) then minFound = indexFound end
      if (indexFound > maxFound) then maxFound = indexFound end
    end
  end

  local fstring = nil
  print("Array length: ", #currentResult)
  print(line)
  for key, value in pairs(currentResult) do
    print(string.format("[%d] : %d", key, value))
  end
  print("First: ", currentResult[minFound], "Last:", currentResult[maxFound])
  print("------")
  currentResult = {}
end
```

Os outputs:

```
Array length:   0
ncqpkzh5twooneoneqfxlqbjjhqsrlkhvdnvtbzpcbj
[9] : 2
[8] : 5
[12] : 1
First:  5       Last:   1
------
Array length:   4
449three45three
[1] : 4
[2] : 4
[3] : 9
[4] : 3
[9] : 4
[10] : 5
First:  4       Last:   5
```

Para ajudar, o `string.find` não reconhece corretamente quando encontra mais de uma ocorrência do termo buscado. Nesta linha: `449three45three`, onde há duas ocorrências de `three`, apenas a primeira é notada, fazendo com que a resposta correta passe despercebida.

Imaginei que poderia existir uma função que resolvesse esse problema de forma mais eficiente, mas preferi fazer manualmente, já que as outras funções internas da linguagem estavam me deixando na mão. Fiz algumas adaptações em um código do Stack Overflow:

```lua
function find_all(text, pattern, start_index)
  local current_index = start_index or 1
  local occurrences = {}
  while true do
    local found_index, _ = string.find(text, pattern, current_index, true)
    if not found_index then
      break
    end
    table.insert(occurrences, found_index)
    print(found_index)
    current_index = found_index + 1
  end
  return occurrences
end
```

Aproveitei para criar a função mais simples possível para calcular o tamanho de uma tabela, pois já estava cansado desse problema, mas não me renderia a um desafio, apesar de começar a escrever os piores blocos de código da história:

```lua
function len(arr)
  local i = 0
  for key, value in pairs(arr) do
    i = i + 1
  end
  return i
end
```

Mesmo assim, o resultado estava incorreto, havia algum caso que estava passando despercebido. Após sete tentativas de submissão, decidi ler as dicas gerais. "Escreva testes". Acho que essa é a última ferramenta para entender todos os casos e ver o que está faltando. Então, lá vamos nós.

Como prefiro evitar pacotes, fiz um sistema simples de teste que recebia um nome, uma execução e um resultado esperado. Os testes que fiz:

```lua
print("-- TESTING LEN FUNCTION --")
test("len of list", a.len({ 1, 2, 3, 4, 5 }), 5)
test("len of hash", a.len({ one = 1, two = 2, three = 3, four = 4, five = 5 }), 5)
test("empty list", a.len({}), 0)

print("-- TESTING FIND FUNCTION --")
test("no ocurence", a.find_all("two", "one"), {})
test("single ocurence", a.find_all("one22222", "one"), { 1 })
test("twice ocurence", a.find_all("one22one222", "one"), { 1, 6 })
test("three ocurence", a.find_all("one22one222one", "one"), { 1, 6, 12 })


print("-- TESTING LINE FUNCTION --")
test("nothing", a.runLine("a"), 0)
test("single digit", a.runLine("1a"), 1)
test("single digit", a.runLine("a1a"), 1)
test("double digit", a.runLine("1a1"), 11)
test("double digit other", a.runLine("1a210k"), 10)
test("random location digit other", a.runLine("a2hhhh0k"), 20)
--
test("single word", a.runLine("kkktwokkkk"), 2)
test("double word", a.runLine("kthreekktwokkkk"), 32)
test("double word other", a.runLine("kthreekonektwokkkk"), 32)
test("double word equal", a.runLine("three38484183three"), 33)
--
test("single word single digit", a.runLine("three38484183"), 33)
test("single word single digit", a.runLine("kkkkthree38484183kkk"), 33)
test("single word single digit", a.runLine("7874"), 74)
--
test("Every number", a.runLine("one"), 1)
test("Every number", a.runLine("two"), 2)
test("Every number", a.runLine("three"), 3)
test("Every number", a.runLine("four"), 4)
test("Every number", a.runLine("five"), 5)
test("Every number", a.runLine("six"), 6)
test("Every number", a.runLine("seven"), 7)
test("Every number", a.runLine("eight"), 8)
test("Every number", a.runLine("nine"), 9)


test("dltwonedvpsqv3 = 23", a.runLine("dltwonedvpsqv3"), 23)
test("threesixninesix = 36", a.runLine("threesixninesix"), 36)
test("1zero = 1", a.runLine("1zero"), 1)
```

# Como Sempre, no Fim, Eu Estava Complicando Demais

Escrevi vários casos de teste para garantir que todas as possibilidades estivessem sendo cobertas. Não consegui pensar em mais nada, então recorri ao Reddit do Advent of Code.

Ao ver algumas perguntas, descobri que, nos casos em que só existe um número, a resposta deveria ser esse número repetido duas vezes, em vez de contá-lo apenas uma vez. Esse foi o meu erro. Pensei demais em todos os casos extras, quando só precisava deixar o programa fazer o que deveria fazer.

E o que podemos aprender com isso? Não complicar demais as coisas, deixar a engenharia seguir seu curso e não interferir no processo (evitando o clássico over-engineering).

Nos meus próximos desafios do Advent of Code, tentarei estabelecer um limite máximo de linhas ou de tratamento de casos, focando apenas no que é especificado no desafio e evitando inventar casos extras.

No final, nem aprendi Lua, porque estava obcecado em encontrar a resposta em vez de entender as funcionalidades da linguagem. Mas o fato de o operador de tamanho estar dando errado já me deixa um pouco relutante em usar essa linguagem novamente, apesar de ela ser originária do Brasil.

# Adendos da vida e dos projetos

Duas coisas importantes:

Faz muito tempo que não escrevo nada por aqui. Estive ultra ocupado entrando agora no meu último ano de faculdade (nem acredito). Estive, também, trabalhando em uma consultoria de programação e produtividade saudável, acredito que é uma das minhas melhores criações dos últimos anos.

Condensando e explicando esses últimos 5 anos de codificação (através desse post parece até que eu comecei ontem, eu sei), 3 anos de trabalho privado e 4 anos de faculdade (obviamente todos esses ocorreram em paralelo).

Espero criar um bom produto, não só apenas com a consultoria (que vai me ajudar a melhorar a forma como explico coisas), mas com os textos de apoio, que de certa forma são ultra-posts de blog. Ainda tenho muito o que trabalhar na consultoria. Se eventualmente os textos somarem 100 páginas, tentarei publica-lo como um livro, mas isso pode levar um bom tempo. De qualquer forma, é um trabalho de iteração, ir adicionando e melhorando os textos e princípios com o tempo.

Segunda coisa: Talvez você tenha notado a mudança repentina na linguagem do site. Sim, estarei escrevendo os próximos posts em português. Apesar do objetivo do site ser um arquivamento do progresso e processo de projetos para aprendizado de todos que poderiam chegar aqui, atualmente na "bolha dev" brasileira temos péssimos conteúdos, muito ruins mesmo. E acho que podemos tentar elevar a barra um pouquinho, de pouco em pouco, pra melhorar a qualidade e competência da comunidade como um todo.

Estou tentando programar mais (já que dei uma parada nos últimos meses, envolvido com outras coisas), além disso tenho outros projetos que quero começar e documentar por aqui e pelo YouTube também. O que não me falta são ideias.

Por enquanto vou fazendo alguns desafios aqui e ali enquanto testo algumas linguagens.

Então nos vemos na próxima!


Sofrendo de Skill-issues em um desafio em Lua

Since I [changed the Rings project to be an isometric tower defense](/blog/a-big-turn-in-the-rings-project) , I've been having some problems with the 2D representation of things in this perspective. Why, you may ask? The thing is that the isometric view is exactly what I described—a representation of the actual 2D top-down game. However, when I started this project, I wasn't considering that isometric would entail more than just a different way of drawing. Unfortunately, this oversight has led to some coding issues

# The beginning of the problem

When I first started making changes to the project's categories, I was only thinking about the mouse interaction with the isometric tiles. So, I followed a tutorial to accomplish this and continued from there.

Initially, my focus was primarily on how the mouse was interacting with the units on those tiles. I considered aspects such as hover detection and the potential problems that could arise, such as:

- What if the unit is taller than the tile? How can I prevent the selection from going to the wrong tile?
  ![test](behind-tower-selection.webp)
- What if there's a unit positioned behind another unit? How can I select the intended one?
  ![second](unselectable-tile.webp)

These small problems overshadowed the magnitude of the challenge I was facing.

# The realization

I implemented the unit placement and deletion functionalities, created a simple targeting system, and developed a Bullet class. I was about to start working on the actual defense mechanisms that the towers would perform.

Next, I began coding the system responsible for firing at the target as soon as it entered the unit's range. However, I encountered a roadblock and couldn't figure out a simple solution. On the surface, it was just a matter of calculating the intersection of circles. Yet, inexplicably, I couldn't make it work.

To create the range ellipse, I used an ellipse since the game had an isometric view. Technically, it wasn't a perfect circle. However, I found myself attempting to calculate ellipse intersections using 2D positions, needlessly complicating everything.

Eventually, when I stopped working on the project, I started reflecting on the issue.

> The state of enemy detection
> ![current-colision](current-colision.webp)

If I have the 2D grid of every tile and the tile position of every unit, why not calculate the range intersection in the top-down view of the tiles and then convert this result later before rendering?

That's precisely what I have started implementing this week as I return to the project after almost a year.

# Let's start by looking at things

Something that has always facilitated this kind of implementation for me is the visualization of the context. Whether it's a simple `print` statement to display the behavior of a variable or even coloring a `<div>` to understand how it affects the entire website's layout (yes, that has happened).

That's why I've decided to develop a top-down debug view for the game. This will not only facilitate the new implementation but also aid in understanding future features and identifying bugs. It's currently a work in progress.

The debug view has helped me realize the issue with my current approach to the isometric perspective. I was constantly thinking in isometric terms instead of considering the underlying 2D representation. In reality, the isometric view doesn't actually exist!

I encountered significant difficulties in determining the actual 2D positions of the elements, to the extent that I had to revisit sections of the code to understand how things were placed, drawn, and recognized in the game.

Questions like how the mouse determines the tile it is hovering over, how the tiles are stored to create a grid, and how to convert coordinates into tile positions (matrix positions) prompted me to reconsider a substantial portion of our rendering and computing pipeline.

> The complexity of the current pipeline far outweighs the simplicity it is meant to achieve."

# Get a step back and rethink the pipeline

Basically, my current plan is to refactor all the isometric-related code to create a simpler pipeline that the entire game can follow, and one that can be easily modified if necessary.

I will store the tile position of every entity and transform it to isometric coordinates during rendering.

> The current debug view ![current-debugger](current-debugger.webp)

Another issue I encountered is the abundance of variables that complicate matters. For instance:

Should the `Unit` class store both `screen_position` and `tile_position`? If I only need the screen position when necessary, wouldn't it be better to transform it dynamically? I don't believe it would require excessive computing power.

```python
class Unit(Entity):
	tile_position: Vector
	screen_position: Vector`
```

---



Why am I passing the game to the `UnitManager` instance? And why did I name the parameter `window`?

```python
class UnitManager:
	def __init__(self, window):
 		self.selected_unit = None
		self.window = window

class Game:
	def __init__(self):
		self.unit_manager = UnitManager(self)
```

As I rewrite this _Top-down to Isometric Logic_, I'm likely to come across more nonsensical code here and there. But for now, that's the plan.

Now, I'll proceed to complete my top-down visualization as I once again refactor this code. Take care not to disrupt your own pipeline in your project!

The Problem with Isometric Graphics


In the [last post](/blog/the-refactoring-process-in-rings-code) I presented you the Rings project, a repository where I (Renato) started implementing some basic systems that I would use in game development in the future. First, as I said in the last post, the idea was to make a rogue-like top-down shooter, but some days ago, I decided that to keep it simple and with the least amount of complexity, Rings should be a Tower Defense game.

# The complexity thing

When you start to think about how to manage multiple abilities that interfere with one another; hundreds of bullets can collide, bounce, go back and pass through stuff. You start to think that Python and Pygame maybe is not the right choice for the job, and starting everything from zero with a new language is kind of a hard decision as well.

But now imagine a game with static units, fixed targets, simple upgrades, and a stateless game loop, you can accept Python as a decent tool for the job.

But, to add more dynamics to the game, I decided to implement an isometric style. The main idea was to bring the semi-3D perspective and the strategi feeling that this kind of graphics brings to games. The first games of **Age of Empires** used those graphics for example. And I think that this is a way to make things more challenging.

![unit_selection](age-of-empires.webp)

# New inspirations and the main idea

Since the rogue-like games exploded in the last few years, the idea is to go against this, for more strategic gameplay. Recently I played [Rogue Tower](https://store.steampowered.com/app/1843760/Rogue_Tower/), rogue-like tower-defense with voxel graphics, its a pretty fun game, but I get bored with it after the first plays, the range of builds is not diverse enough that you want to experiment with other types of stats and machines.

A game that does this part very well is [ Despot's Game: Dystopian Army Builder](https://store.steampowered.com/app/1227280/Despots_Game_Dystopian_Army_Builder/), which goes for an auto-battle (TFT vibes) with class combinations and power-ups.

So, the idea is to mess up with those concepts in a [Bloons TD 6](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwjH36jBtbX6AhV7s5UCHYc0ALMQFnoECAsQAQ&url=https%3A%2F%2Fstore.steampowered.com%2Fapp%2F960090%2FBloons_TD_6%2F&usg=AOvVaw1Q3-OUytRLn3tVpRT1PUBm) style as well. With a variety of units each one with its purpose and class, so you can play with those kinds of combinations.

Since I'm a noobie game developer, my ideas and implementations probably will go pretty badly, but the idea is to experiment with everything before making a serious game.

# The Game so far

It's important to say that we don't have any style concept formed so far, don't have gameplay and the base of Pygame start code continues there. For the first interactions of the game, I focused on doing the isometric stuff (that is harder than it looks). Then I created an `UnitManager` to take care of the unit placement and delete.

To make the Unit selection I needed to work better on detecting which Tile and which Unit I was hovering with the mouse, It's kind of tricky but it does the job.
![unit_selection](unit_selection.webp)

I still need to improve the isometric-to-plane logic, because now I'm stuck on the code to detect if an enemy enters a unit range, and I cannot use the isometric position straight ahead, I need to make some kind of conversion. I need to calculate those collisions in the flat plane and then, only transform to isometric when needed (to draw and calculate mouse collision with units).

I made a simple shoot system just to try it out, but need to fix those collisions before showing anything.

# Some problems

Finally, as things progress it get's harder to develop some stuf, that's why we should build things different. But at the same time we need to make things work before refactoring it. Another thing that I'm facing is unit testing problems.

What, where and how to test thing in a video-game code? Should you test it with all things turned on? (like graphics) Or should you just test the intern things like sub-functions? Given that things change brutly during early development, those test can start to requiring more work then the real code, and it's kind ok to do that, since those tests hold your software together and protected from future mistakes.

Anyways, I need to start testing as soon as possible. I Will write abou testing when I make it.


A Big Turn in The Rings Project


Hi There! I would like to introduce to you one of my (and Back to Pixels) project **Rings**. And perhaps show some big refactorings
that I did some days ago.

# Presenting Rings

Rings is a pygame video-game project that initially was inspired by [Enter the Gungeon](https://enterthegungeon.com) and [Nuclear Throne](https://nuclearthrone.com) (even the sprite animation test was done using its sprites). But with time (and some studies) I realized that this scope was too big for my first game, and by the time I was pretty into [Vampire Survivors](https://store.steampowered.com/app/1794680/Vampire_Survivors/), so I decided to redirect Rings to be a "stand-still" rogue-like game. Aiming to try some video-game software architecture and push to the limits that python can do as a game development language!

> The name rings was referring to the upgrades in the game, that would be rings that you could use, a maximum of 10.

But a complete game is still a big scope for someone that studies and has a full-time job. So, my current idea is to develop each feature of a simple game development framework just to experiment with some module architectures.

And here today I will show you what was _Rings_ was before and after some cool structural changes that I made based on some simple things that I've learned recently.

# How It Was and Where it is Going

Since I'm just developing feature to feature, my architecture thing was not that important, so I kept the code struct as the simple pygame tutorial would give you, which is, extremely bad, but with the simple _check-events_, _update entities_, _render entities_ order.

But after seeing some [DaFluffyPotato](https://www.youtube.com/c/DaFluffyPotato) live streams I start to recognize a pattern in his code. He put everything into a _Game_ class, and passes this game class to everyone inside it (this part is pretty dangerous but ok), and inside this class, he has a _world_ attribute (of the class World) and an _Input_ attribute (of the class Input) and so on for every major thing in his game. He also had some classic structs such as a list of _entities_ and a list of projectiles.

Anyways, this architecture can help a lot such in debugging (because um can tear apart things easily) and in modularity.

So that's where I aimed to when refactoring Rings for (almost) the first time.

# Some Bad Code

Here I will show you how the code was (it is a little bit longer, so maybe I will change it in the future)

```python
configs = json.load(open('config.json'))

pygame.init()
pygame.mixer.pre_init(44100, -16, 2, 512)
pygame.mixer.set_num_channels(32)
pygame.display.set_caption("Rings")
pygame.mouse.set_visible(False)

FONT = pygame.font.Font("res/Pixellari.ttf", 22)

global debugging
game_time = 0
base_screen_size = configs['resolution']
screen = pygame.display.set_mode(
	(base_screen_size[0],base_screen_size[1]),0,32
)
display = pygame.Surface((300,200))
clock = pygame.time.Clock()
screen_real_size = display.get_size()
camera = Vector(0,0)

player = Player(Vector(10,10))
player.load_animations()

TILE_SIZE = 20

game_map = [...]

cursor_img = pygame.transform.scale(
	pygame.image.load('res/mouse.png').convert(), (44, 44)
)

cursor_img.set_colorkey((255, 0, 0))

camera_speed = 20
debugging = True
running = True

while running:

	for event in pygame.event.get():
		check_events(event,player)

	mx, my = pygame.mouse.get_pos()

	true_mx = mx
	true_my = my

	mx -= (screen.get_width() - base_screen_size[0]) // 3
	my -= (screen.get_height() - base_screen_size[1]) // 3
	mx /= base_screen_size[0] / display.get_width()
	my /= base_screen_size[1] / display.get_height()

	camera.x = player.position.x + 7 - screen_real_size[0] /2 # the +7 is half of the size of the player, to certralyze
	camera.y = player.position.y + 7 - screen_real_size[1] /2

	player.is_not_walking = not player.is_moving_right and not 		player.is_moving_up and not player.is_moving_down and not player.is_moving_left


	scroll = camera
	scroll.x = int(scroll.x)
	scroll.y = int(scroll.y)

	display.fill((30,30,30))

	collision_tiles = []
	tile_rects =[]

	y = 0

	for row in game_map:

	x= 0

	for tile in row:
		#<big tiles logic and draw>
		for t in row:
			#<more logic and draw world stuff>

	player.update(mx, collision_tiles,camera)
	player.draw(display,debugging)

	screen.blit(pygame.transform.scale(display, base_screen_size),

	((screen.get_width() - base_screen_size[0]) // 2,

	(screen.get_height() - base_screen_size[1]) // 2))

	screen.blit(cursor_img, (true_mx // 3 * 3 + 1, true_my // 3 * 3 + 1))

	if debugging:

		utils.draw_text(FONT, "FPS: " + str(int(clock.get_fps())), screen, (10,10))

	pygame.display.update()
	clock.tick(60)
```

> I removed some unnecessary parts

# Some less-bad code

```python
class Game:
	_entities: list
	game_time: int
	player: Player
	window: Window
	world: World
	mouse: Mouse
	camera: Camera

	def __init__(self):
		configs = json.load(open("config.json"))
		self.window = Window(configs)
		self.mouse = Mouse(self.window)
		self.world = World()
		self.player = Player(self)
		self.player.load_animations()
		self.camera = Camera(
				self.player,
				self.window.screen_real_size
		)


		self._entities = []
		self._entities.append(self.player)
		self.running = True
		self.clock = pygame.time.Clock()
		self.FONT = pygame.font.Font("res/Pixellari.ttf", 22)


	def update(self):
		self.world.update()
		self.mouse.update()
		self.camera.update()
		for entitiy in self._entities:
			entitiy.update()

		pygame.display.update()
		self.clock.tick(60)

	def draw(self):
		self.window.display.fill((30, 30, 30))
		self.world.draw(self.window.display, self.camera.position)

		for entitiy in self._entities:
			entitiy.draw(self.window.display, self.camera.position)


		self.window.blit_displays()
		self.mouse.draw(self.window.screen)

	def run(self):
		while self.running:
			self.check_events()
			self.update()
			self.draw()

game = Game().run()
```

Even with this "better" code, there are always things to improve everywhere. Such as an Input class to handle all the input commands and logic (that I hid in this example), or some particles and sound managers (that I didn't implement yet).

As Uncle Bob says in "Clean Architecture":

> Good (clean and well architectured) code, should look like a well-written poem

The new rings architecture looks like some Ok poem, but I think it could be better, mainly in the _Player_ class (the animation system is kind of messed up). In the end, all I did was hide things properly and reallocate them where they should be.

All the world logic and drawing are inside the _World_ class, for example, and the same thing applies to all the other pieces of the game. It's clear that I don't have much to organize, but it was a good starting point to do all these refactorings.

# What Rings have until now?

Rings started as an experiment, just me trying to implement some cool game-development features. So, the project doesn't have much, just some split, badly implemented simple features, like particles, animations, collisions, and sparks (that I just copied from DaFlufy). But those simple things that I have will be re-write and documented here in the future.

For now, the game looks something like this:

![game-screen-shot](game-screen-shot.webp)

> I used the Nuclear Throne animation to test some stuff ;)

# Conclusion

As I said, Rings are only the start, and I pretend to turn it into a simple rogue-like game, and that's some of the things I will bring her to the game-studio blog.

I will bring some cool implementations and mainly focus on game-design architecture.

Hope you like it and Thanks for reading! You can follow all **Rings** articles in [tag/rings](/blog/tag/rings)

You can check out this project on my [RenatoCesraF/Rings](https://github.com/RenatoCesarF/Rings)


The Refactoring process in Rings code


# What is an Anchor Link?
According to [doc.sitecore](https://doc.sitecore.com/xp/en/users/100/sitecore-experience-platform/create-an-anchor-and-link-to-it.html#:~:text=An%20anchor%20is%20an%20HTML,the%20middle%20of%20another%20page.) an **Anchor Links**

>**is an HTML code that is used as a bookmark to create a link to a particular section within a page**. For example, it could be a Back to top link that takes the user to the top of the current page, or it could be a link to a section in the middle of another page.

So, it's like bookmarks. You click on an anchor link and you get moved there automatically. It's pretty cool and I always found it very useful as well. Like in [Wikipedia](https://en.wikipedia.org/) pages, the summary made with anchor links helps you to find the exact part that you want.

And my idea was to have something like that in our blog as well. In the future, we will have big articles with multiple parts, and the anchor links are a good way to travel fast through the article.

# How Anchor Links Works 
To use an anchor link you need a `<a>` tag to serve as the redirector. But the key thing is the *href* passed to this tag, which is the ID of the item that you want to jump to. So if you want to go to the title **Why not use replaceAll()** from this you would need to add an id to this title inside its HTML:

```html
<h1 id="why-not-use-replaceall"> Why not use replaceAll() </h1>
```

So our `<a>` tag would look something like this:
```html
<a href="#why-not-use-replaceall"> Link to title </a> 
```
 Then, if you click on this tag, the website would search for an element with this id and scroll to it, turning your URL into.
 `https://backtopixels.vercel.app/blog/how-to-build-an-auto-gerenated-summary#why-not-use-replacealll`
 
 It's very simple to understand right? The browser just searches for the element with the same ID as the link.
 
 # Automating  Titles IDs
 Of course, you wouldn't add ids and links to every title that you have on your page, you can automate that very easily.
 
 I use [*react-markdown*](https://www.npmjs.com/package/react-markdown) to make the MarkDown transcription to HTML (you can read more about it in [this](/blog/the-way-we-do-markdown-transcription) post). With this package, you can actually change the returning element to each translation. So I can change every *h2* to an *h1* or add more styles, classes and etc. To add the IDs I could just format the text inside the *h1* and added it as the ID of this element, but you don't need to. You can just add the [remark-slug](https://www.npmjs.com/package/remark-slug) package as a plugin to the *react-markdown* and it does all this for you.
 
 ```jsx
<ReactMarkdown 
	   remarkPlugins={[remarkSlug]}>
	{yourMarkDown} 
</ReactMarkdown>
```
 
 That is half the work done!
 
 # The Summary component
 What the summary component will do is receive your markdown (you can receive the HTML as well if you want), find all the titles, separate them, format the links, and create a list of `<a>` tags with the name of the title as it's text, and the name formated as the link:
 ```jsx
<a href={`#${link}`}>{name}</a>
```
And then everything just works!

# Getting Titles and Links
As I said before, our component will receive the entire markdown to get the titles. To do so, we will separate all the text by its line breaks with `split("/n")`, and then search for the lines that start with *#*.
```js
const textLines = content.split('\n');
const titles: string[] = [];

textLines.map(((line: string) =>{ // for every line of the content
	if(line.startsWith("# ")){
 		titles.push(line); // get the line that starts with "#"
	}
}));
```

Now that we have every title separated we can format it to get the link. As I'm using typescript, I decided to transform it into an *interface*
```ts
interface TitleAnchorLink{
	href: string,
 	name: string,
}
```

Now we will declare two functions, one to **format** the link and another to generate the *TitleAnchorLink*:

```ts
const formatTitleLink = (title: string): string =>{
	let link = title.slice(2).toLowerCase().trim().split(" ").join("-");
	link = removeSymbolsFromLink(link);
	return link;
}
```
Let me explain, this **formatTittleLink** function: first we *slice* the first two characters from the line, because those characters are `# `, the declaration of the title in markdown, and we don't need it. Then we remove all extra spaces with `trim()` and finally we replace all spaces by trace (-). The reason why I used `split(" ").join("-")` instead of `replaceAll(" ", "-")` is because *replaceAll* is not supported in all browsers, and not supported by the Vercel server. The *split* separates our string in a list by every space, then the *join* transforms this list into a string separating every item by *-*.

Another thing to explain is this function *removeSymbolsFromLink*, as you may notice URLs don't have certain characters, like question-marks, exclamations, brackets, math signs and etc, that may appear in our titles. So we create a list of characters that should be removed, iterate through them, and replace the character with a blank space. 

```ts
const symbolsToRemove = ["?", "/", "@", "+",".", "!", "%", "$", "(", ")", "*", "<", ">", "&"];// you can add more if you want
const removeSymbolsFromLink = (link: string): string =>{
	symbolsToRemove.map((symbol: string) => {
		link = link.split(symbol).join(""); //remove symbol from the string
	});
	return link;
}
//This function still has room for improvement
```

Now we can use those functions in our *getTitleLinks*:

```ts
const getTitleLinks = (titles: string[]): TitleAnchorLink[] =>{
	 const titleLinks: TitleAnchorLink[] = [];
	 titles.map((title: string) =>{
		 const link = formatTitleLink(title);
		 title = title.slice(2);
	 	titleLinks.push({name: title, href: link});
	 });

	 return titleLinks;
}
```
Let's review what is been done.
1. Separate every line of the text
2. Get the lines that start with *#*
3. Remove the *#*, replace spaces with *-* and remove the unwanted sign
4. create the object *TitleAnchorLink* with that information

obs: I'm also removing the `# ` from our title itself, so it becomes just the title without MD notations

Now we have all the information we need to execute our Summary Component
```tsx
const AutoGeneratedSumarry = ({content}: AutoGeneratedSumarryProps) =>{ 
	const titles = getPostTitles(content);
	const titleLinks: TitleAnchorLink[] = getTitleLinks(titles);


	if(titleLinks.length == 0) return <></>;

	return(
		<div className="post-sumarry">
		<h3>Summary</h3>
			<ul>
				{titleLinks.map((anchor: TitleAnchorLink, index: number) => {
					return (
						<li key={index}>
							<Link passHref href={"#" + anchor.href}>
								{anchor.name}
							</Link>
						</li>
					);
				})}
			</ul>
		</div>
 	);
}
```

Let's see what this component does.
- First, get the TitleAnchorLinks using those cool functions
- Then, check if the list of Title links is empty, if they are, return an empty component
- Finally, for every link in our list, return an element with the content as the name and the link as a # followed by the formated link.

And it's done!

---
I added some CSS and the end result is this one

![gif-summary-result](git-summary-working.gif)

Of course, that exist some cool improvements that you can do, like an open and close animation, subtitles indented inside titles, and more. 

If you have any questions you can send them to me, Just open my profile ([Renato](/team/renato)) and send me on any social media.

There are many new things in this blog that I implemented since the last update, and this summary was one of those. I will write a post about the new stuff in the future.

Bye Bye!👋👋

Implementing An Auto-Generated Summary


In this post, which is kind of a tutorial, I will show you how I [Renato](/team/renato) implemented this blog's dark theme system, how to implement it on your own with CSS only. How CSS variables work and why use CSS only for it instead of a simples package.

# Understanding CSS Variables
Like in any real programming language you can declare variables and use them, even not been a programming language you can declare variables in CSS as well. 

A CSS variable is declared using double-dash `--name` plus a semicoma and then the value of this variable:  `--example: blue;`.

These variables are created inside scopes and can only be used for those inside that scope. So if you create your variable in a `.blog-page{}` scope, it will only be available for its children.

Using a CSS variable is like calling a function `var()` with the parameter being the name of your variable. 

Look this example of the scope and use of a variable:
```css
.cool-page{
	--best-color: #382F60
}
.cool-page h1{
	color: var(--best-color)
}

.another-page h1{
	color: var(--best-color)
}
```

In the first `h1` use (*.cool-page h1*) the variable will work perfectly. But in the second one (*.another-page h1*) it will not work. Because the variable is only declared in the `.cool-page` scope.

CSS variables can be anything:
- Colors;
- Sizes;
- Fonts;
- Borders;
- Shadow;

And any kind of CSS value that can be used in CSS can be stored in variables to be used later.

When I started this website I created all my variables in the `:root` class, so every other element could use it (you can use HTML or body tag instead as well).

Another thing to notice is that you can **overwrite** variable values in another CSS element, so if you declare `--cool-color` in the *root* element, you can overwrite it inside of *body* and change the value for all those which are inside of it.

Those variables are very useful if you want to test palettes, change fonts easily, etc. So even if you are not going to a *dark-theme* implementation, I recommend you to use CSS variables.

# Making Dark Theme With CSS Only
So, you can define and use variables in all your code. If you define it all in the `:root` you can use it anywhere. Changing only one variable you will change the value for all the elements that use it.

The dark theme with CSS only is based on this idea:

> Build all your styles with variables, then, when you change the theme, change the value of all the variables.

To change these variables we can define the variables in the `body{}` element. Define your variables there and create a `body.dark{}` element as well and overwrite all the variables there:

```css
body{
	--cool-color: #382F60;
	--font-color: #2d2d2d;
}
body.dark-theme{
	--cool-color: black;
	--font-color: white;
}
```

The idea is to change the *body* class depending on the theme that you want to use.

---
If you declare all your variables and overwrite them in the `body.dark` you can already test it by adding a *class* to the *body* in your browser.

# Changing Themes Inside Next.JS
There are problems changing CSS inside *Next-JS* thus it's a server-side rendering, but it's still possible.

But first a context: I created a theme switcher on my page, and the code that I will explain now is inside this component.

---
Thus we are using Next-JS, we need to set some *useState* to manage the state of the theme. Then we can create a simple function to change the theme depending on the theme that is already set.

```jsx
 const [theme, setTheme] = useState('light-theme');

 const switchTheme = () => {
	 if(theme === 'dark-theme'){
		 setTheme('light-theme');
		 return;
	 }
	 else{
	 	setTheme('dark-theme');
	 }
 }
```

But until here we are just saving this value and not applying it in the class of the body. To do so, we will need a `useEffect()`. This *useEffect* has two reasons to be here.

The first is to let us know if the website is loaded, thus this function only executes when the website finishes the pre-load.

And the second is to know if the code is being executed in the server (during the server rendering) or during the client access.  That's why we need to have a **loaded** state. We will set this **loaded state** as *true* if the  `useEffect` execute and then we will pass to the *body* the class of the theme that we are at.

```js
 const [loaded, setLoaded] = useState(false);


 useEffect(() => {  // if we are at the client side,
	 setLoaded(true); //  set loaded as true
	 document.body.className = theme; // and add the class to the body
 });

```

If you don't use the `useEffect`, the framework might don't build the project or even don't run the page.

---
Now, when constructing your *theme switcher* you need to use this *load* variable to check if is everything allright to render (if we are at the client and if all the page has already been rendered):

```tsx
 return(
	 <div onClick={() => switchTheme()}>
		 {
			 loaded?
				[themeSwitcher]
			 : <></>
		 }
	 </div>
 )
 ```

# No Colors on Loading Problem
Thus, the code to decide the theme that is active only executes when the page loads. You may have a problem with no defined colors when your website starts to load (before the "choose theme" function be executed). To fix that you have two options:

## Option 1
Instead of creating two classes for the body `.dark-theme` and `.light-theme` you can create only one and add or remove it on the *change theme* code, instead of changing from one to another. In this way, the no-class colors will be loaded instantly.

## Option 2
You can define *general-colors* (that don't change) and main colors in the `:root` element. In this way, these *general-colors* will be loaded on start and overwritten if needed after the *change theme* code execute. This helps if you want to add more themes in the future and it's the option that I choose, mainly for readability.

```css
:root{
	--header-color: blue;
}
body.light-theme{
	/*just uses the defined in the :root*/
}
body.dark-theme{
	--header-color: black;
	/*overwrite the root color after the loading*/
}
```


# Other Methods
Of course, you could  use a package, but personally I always rather do it myself instead. In this way, you learn more about your tools and how things work.

Anyways, it's that. Any questions or advice you can send me on my [Twitter](https://twitter.com/nerat0). I always post some updates about this blog there as well. See ya!


The Easiest Way to Achieve Dark-Theme


All the posts of this website are written in `.md` files, which is a much much better way to write content without losing your mind with HTML opening and closing tags. Websites such as Medium, LinkedIn, and GitHub use this Markation language to save and write their posts and **READMEs**. So nothing better to use it as well. The Mark-Down also provides an easy way to write for a non-programmer person, so it's very good for our future teammates as well. Thus this is a static website all the mark-down translation happens in the build time, instead of in the "consuming" time. That is, this work is done by the server when a new version of the website comes out, and not by you, the lovely user. 

# Configuring the Mark-Down file
The `.md` file is configured by a header, where you can declare variables to use later, those variables can be anything, lists, numbers, string, etc. The configuration of this post looks something like this:

```yaml
---
title: 'The Way We Do MarkDown Transcriptions'
date: '09/02/2022'
author: 'renato'
cover_image: 'cover'
excerpt: "Explaining how our .md to HTML works and the new features I just implement"
categories: [BLOG, DESIGN, PROGRAMMING, NEXTJS]
---
```

The title, date, excerpt are very auto-explanation. The author is just a key to getting its info later and the categories the same (the upper case is just something for visualization). The cover image is very simples as well, is the name of the image that will be used as a cover. You can read more about the way we deal with images in [this post about it](/blog/default-images-and-our-images-architecture). 

After this header comes to the post itself. We use [grey-matter](https://www.npmjs.com/package/grey-matter) to separate the content and the header variables. Then we use a `createPost()` function to get the detailed information of the author and each category.

# The Transcription It Self 
In the first versions of this website, we used to use [markdown-it](https://www.npmjs.com/package/markdown-it) to transform `.md` files into HTML. But MarkDown-it has some problems, that is, fewer features.  MarkDown-it doesn't provide a replacement of translated HTML (so you cant use code highlight in code block). This package doesn't provide many other `.md` translation like
- check-boxes
- tables
- footer notes

Now, for the other side, [react-markdown](https://github.com/remarkjs/react-markdown) provides all of it and much more. Thus react-markdown uses remark as an API and it has some kind of modular separation, it provides the addition of plugins, such as remark and rehype plugins. React-markdown also provides a way to replace the HTML translated with functions. So if I want to change every link that has my name to a golden and shines name, I actually can.

# Amazing Possibilities
Using this kind of replacement I was able to replace every code block with a Prism Syntax Highlighter React element that can provide us with those beautiful code blocks. Or for example the replacement of every image by a zoomable image element that I created. Or even the stylization of our check-boxes. There are many other things to replace yet, and the code of it is very ugly but it is stills very useful in this case. 

I also realized some days ago this plugin thing of the package and added some of those to our project. Like tables and footer-notes. I still need to test it on smartphones, etc but it is already working[^1] . The go-to footer not is working fine, but the come back doesn't for no reason. Maybe I implemented something wrong, but it should work. The tables thing was something that I was missing up for future posts, and now I don't.

We still using grey-matter for the post card, thus the post just needs simple transcription.

---

Now, here is a table example to test it out:

Feature | status
-------| ------
Tables | done
Footer-notes | done
Hover-teammate-name | stylizing
zoomable-images | cool but not perfect
Dark-theme | don't have any idea
News-letter | what? how?
Writer/post info | Designing

# More Slylish Quotes
Another thing that I added thus those ones, was a property style for the `<blockquote>` component. That goes like this:

>Now I've heard there was a secret chord
That David played, and it pleased the Lord
But you don't really care for music, do you?

I'm not sure about this grey background, but I think it's ok!

# RSS Feeds
I still messing around with this, but anyways. Now we have an RSS feed generator script. So you can get its link and paste it into any Feed reader to have these posts in your App. It still with some images and date problems, but it works, and it's very cool.

* [x] RSS feeds and links component

Also created a simple component to hold these links at the end of each post and blog page. as you can see here ⬇️ 

[^1]: See?



The Way We Do MarkDown Transcriptions




I just finished the implementation of the default images that appear on posts that don't have a cover. It was something that wants to implement because those old flat colors were very ugly.

![posts-exemple](posts-exemple.webp)
 
The logic is to have those default images saved locally and just change the `cover_image` URL to a default one when the post doesn't have a `cover_image` defined. We can choose default cover images as well using **number**. 

# How To make Good-Looking Cover Images
Yes! Those images are pretty cool. I found an online generator of section-transition images to be used in websites, but the images are so cool that can be used anywhere (you can check out the [generator here](https://app.haikei.app/)).

![generator-site](generator-site.webp)

So I changed the colors and play a little bit with the configuration in some generation options and ended up with this ones:

![default-image-1](default-image-1.webp)

---

![default-image-2](default-image-2.webp)

---

![default-image-3](default-image-3.webp)

---

![default-image-4](default-image-4.webp)

---

# How The System Works

The system is very simple. We just verify if the `cover_image` variable is a valid image, or if it's of the type *Number*. If the image isn't valid or is a number we choose one of the four default images and use its URL instead. Let's see: 

# How We Store Posts Images

Before understanding how the default images work, you need to understand how we store our post-images in the first place. All the website logic, programming, design was made by me ([Renato](/team/renato)). And I do not have sure that this is the best architecture option to store posts images, but is the one that most fits my case. Maybe in the future, it changes (I hope not). But for now, it is what it is.

We have a **posts** folder in the root directory. inside this folder, there is every single post written in a `.md` format. The name of each post is its name in lower keys separated by a dash/trace '-'. For example, this post file name is `default-images-and-our-images-architecture`. This name serves as **slug**/ID for the post. Now inside our `public/images` folder, we have another **posts** folder, this one has one folder for each post written, the name of those subfolders are the same as the post that it belongs to. Inside those subfolders, we store all the images used in each post. 

![folder-organization](folder-organization.webp)

I think this is a good approach to storing multiple blog images. It would be a terrible solution to just throw every single image inside the same folder, and not separate it by post. How would you find an old image inside it? How would you manage thousands and thousands of images when the website grows?

Another thing is the dash/trace ('-') nomenclature chosen. I know that CammelCase is good when you are coding, but it's good when you are using the code font, and not a file / OS font. It's terrible to read it in almost all common fonts. So the dash is a good choice. And why not an underscore ('_')? To tell the truth, is simpler than it looks: it takes more work to type. Instead of using `shift + '-'` to write every simple space in the word, just use the dash. In the end, it's like a space-bar on the top of the keyboard :)

---

In this way, we have an organized way to store all our images knowing where each one is always.


# And The Default Images?

Each *default image* is saved in a `default-images` folder, inside `images/posts` as a number (1 to 4) in `webp` format (because of performance). 

Our "choose image function" is called `getCoverImage()`.

It receives a **slug** And a **image_name**. This *image_name* is set in the header of the `.md` file. It just contains the name of the image that will be on the cover. Why just the name? Because we already have the **slug** of the post (that is, the *name* of the post folder where all the images are). So we can get any image just using `images/posts/{slug}/{image_name}.webp`.

> I just realized that I can use this same strategy to get every single image inside the post. So instead of declaring it `images/posts/default-images-and-how-we-store-images/image-name.webp` we can just use `ìmages-name.webp` for now on!

Anyway, The first thing we do in our `getCoverImage()` is to create the return variable and check if the image exists or if the type of the variable is a number. 

```js
var coverImage;

if(!isImageCoverValid(slug, image_name) || typeof(image_name) === "number"){
	 var defaultImageIndex = image_name || Math.floor(Math.random() * 4) + 1;
	 coverImage = `/images/posts/default-images/${defaultImageIndex}.webp`;
	 return coverImage;
}
```

if it's a number, that means that the author wants to choose one of the default images. So just set the `defaultImageIndex` as this number. But if it is not valid (is null or starts with "HTTP" or is not in the post folder) choose a random number to get a random default image in the next line. So the cover image source string is made, and the value returned to the post.cover_image.

Now, if the image is valid, we just create the source path using the variables (slug and image_name) and return it:

```js
coverImage = `/images/posts/${slug}/${image_name}.webp`; 
return coverImage;
```

Look how the **isImageCoverValid()** works inside:

```js
const isImageCoverValid = (slug: string, image_name: any) => {
	const isImageTextValid: boolean = (
		typeof(image_name) === "string" && 
		!image_name.toString.startsWith('https')
	)

	if(image_name === null || !isImageTextValid ){
		return false;
	}

	var imageExistInFolder = false; 
	const images: string[] = readdirSync(join(`public/images/posts/${slug}`));

	for(let image of images) {
		 if(image.replace('.webp', '') === image_name){
			 imageExistInFolder = true;
			 break;
		 }
	}

	return imageExistInFolder;
}
```

We check if is a text and if has *HTTP* (we do not allow other cloud images). If is not null and is a valid text we create a variable `imageExistInFolder` and start to search for the image inside the post folder. If the image appears we *break* the loop and return that the image is valid. So doesn't need to use a default image. 


certainly

Of course, there is room for improvement all over it, (like creating the images with Python instead of using HTML tag to make the post date in the middle). But for now, it's this.

Anyways, this was the best post written until now. So I hope you enjoy it!

Default Images And Our Images Architecture


Some days ago one of our teammates [Tayna](/team/tayna) send me a Drive folder with some versions of a logo to this website. It's a really good-looking logo, and she created a Name as well **Coding Ideas**. 


I think it's a good name and a good logo. So thus we don't have a logo and name yet I decided to use those ones until we create (or not) a better one (I think it will be hard to happen).

So last day I visit [Bruno](/team/bruno), another teammate, and start to update all the website to this new logo (we ended up changing the colors as well).

Today I "finish" the implementation, the Twitter share still with some problems, but everything else is working properly.

Here's the blog page:
![blog-page-provisional-logo](new-blog-page.webp)

How it looks on share in Twitter and WhatsApp:
![logo-in-twitter](logo-in-twitter.webp)

---

![logo-in-wpp](logo-in-wpp.webp)

---

# Animations are very cool
Given that I've been searching a lot about meta tags, SEO, and other web development matters, other web developers blogs have been showing up for me with articles about that, one of them was the [Philu blog](https://phiilu.com/) It's a very well done React js Website so I study it's code and decided to add those kinds of animations for this Website as well.

The implementation is very simple, but with a pretty good-looking result.

![animations-gif](animations-gif.gif)

Basically, you change every `<div>` that you want to animate by a `<motion.div>` that comes from the package [**Framer Motion**](https://www.framer.com/) the base for the animations.

Then you can provide some options for each animated `div` (this is something that I don't fully understand yet). 

In the end, I added animations just for the important things, I regret it a little because the animations drop the performance of the page from 64 to 41 according to the [web.dev measure page](https://web.dev/measure/). 

Talking about that, the performance is something that is still very important after all. I need to implement `React.lazy` and other *serverSide* things to speed it up.

# In Development GIF
Another cool thing that I added was a [Lottie](https://lottiefiles.com/what-is-lottie) gif of "in development" to use in the pages that don't have content yet. It was pretty easy but I enjoy the feeling of it


![under-dev-gif](in-development.gif)

# Tag system
My main idea to filter the blog posts is to use a tag system, where each post can have many tags to make it easier for the user to find what he/she is looking for. In the future, you will be able to filter posts by any number of specific tags, searching its name and description or by author. 

There will be multiple types of tags, for projects, languages, categories, etc. There is no filter yet, but you can already see the tags in each post. If the post has more than 2 tags, you can hover it to reveal the others. It's a very cute animation though.

![tags-animation](tags-animation.gif)

# Last improvements
In this last week I didn't add new features, just fix animations, performance issues, and other CSS things. But one thing made me smile:

Before, to make the posts appear in Social Media as I showed in the [last post](/blog/discovering-meta-tags-plus-website-uptades). I needed to upload the cover image to the imigur website (that only accepts PNG and not WEBP) and link it in my blog post. But now I discovered that if I use the entire path I can use it normally in my post and the share continues working. It's something very stupid that made me happy.

---

But anyway, the development of this website continues in the next post. The fun thing is that I never know what is the next thing that I gonna add here, this mystery makes me excited to develop more

A Provisional Logo And Name



From now on, if you share one of our posts on *social media* it will look something like that:

![post-in-twitter](post-in-twitter.webp)
You can read the post of the image [here](/blog/reunion-0-1).

It also works in *instagram*, *whatsapp*, *facebook*, *Discord* and *LinkedIn*.

I have never known how this kind of interpretation was made. The only thing like that I knew was the RSS system that many podcast providers use. The RSS is a bunch of HTML tags with all the information of the podcast. First I thought that this cover image and description was based on RSS ass well. But no. It's all **Meta Tags**.

# More About Meta Tags

The only thing that I knew about meta tags is that they could change the *favi.icon*, the bar color, and the title of the website. But searching a little bit about meta tags to fix a Next.Js bug, I came across another kind of meta tags, with properties like *og* (OpenGraph) and *twitter*.

This *OpenGraph* protocol was created by facebook and:
> enables developers to integrate their pages into Facebook's global mapping/tracking tool Social Graph.
according to the [Facebook Platform Wikipedia](https://en.wikipedia.org/wiki/Facebook_Platform).
Over time more websites and social media start to use it as well.

# How I implemented it here

First I added a simple `<head>`component with general metatag info in the *_app.tsx* file. Info like:
- Creator
- Theme-color
- copyright
- og:locale

Since this kind of value doesn't change through the website.

---

And in every single page (Home, Team, Blog) I added more additional info like the description of the page and the title.
 
But the cool thing is on the *post* page. Each post, when generated as a static page, generates its meta tags with all its information. Sucha as:
- post Description
- post author
- keywords
- All the og tags 
    - type
    - url
    - title
    - image
- all twitter tags
    - card type
    - image
    - title
    - description
    - creator
    - domain

And more not so important tags, like height and width of images, etc.

Just using this it's possible to implement the cool share card in social Media. Look how my post tags look like now:

![post-meta-tags](post-meta-tags.webp)

The only thing that give me some problems was the Twitter postcard. I don't know why, but Twitter only accepts when you put the post image coming from the internet, and not local. I will make some new tests to see if this deduction is correct.

# New features in this website

Since the last update ([reunion 0.1](/blog/reunion-0-1)) I made some new things here. But the coolest and more important is the animations.

So yes, we finally added the Header, but the cool part is the animation that I, kind of, found. I was creating a *Media Query* for smartphones and then, when I was adding a transition of states, the VS code start to suggest some [Bézier curvs](https://en.wikipedia.org/wiki/B%C3%A9zier_curve) as animations transition parameters. I tested someones and liked this one that I'm using now. After this, I study some animations from [codepen](https://codepen.io/) and made this one. Look how the header is looking great:

![header-animations](header-animations.gif)

I had some new animation ideas to implement in the future, so wait for it!

Discovering Meta tags + Website Updates


Yesterday (01/05/2022) we made our first reunion, sadly with only two of us personally ([Renato](/team/renato) and [Bruno](/team/bruno)) and one via Google Meet. But even in this situation, we did a lot of progress.

-   We choose a font: Robot for the body of every text (Maybe try Open Sans in the future).
-   We tried some palette colors 
-   Improve the overall CSS structure with new variables

# Choosing Fonts
To choose the font we made some kind of display of the possible options. Between the options was:

- Mukto
- Inconsolata
- Open Sans
- Roboto
- Nunito

We ended up with Roboto, just because the time was running out. Maybe I will test some Open Sans in the future


# Trying Palettes

It was a lot of fun and we are excited to improve each time more this website and write new and improved articles here.

  
Between the pallets tested we have these:

![mouse-palette](mouse-palette.webp)

---

![granito-palette](granito-palette.webp)

---

![baleia-palette](baleia-palette.webp)

---

![cimento-palette](cimento-palette.webp)

----

I liked the gray one. But will try nome others in the future, thus it's nothing defined yet. Maybe a bluer grey. 

  

To improve the palette swap I created many variables to centralize the styles of the website. In the future, I want to make a Dark Theme as well, but to do this will need to make some changes again. 

  

And to document the moment, we decided to shoot some photos *(and I made some effects by hand)*:

![painted-1](painted-us.webp)

Reunion 0.1



Add code highlight, and it's preaty cool! Like That:
```python
def preaty_cool_python_function(cool_param):
    if(not cool_param):
        return
    print(cool_param)
```

it has many themes and options.

All posts are writen in MarkDown files, so it's possible to choose a language in every code-section. And also choose a highlight theme for the post using the configuration header


Still need to add more themes (load each one from the package into a external file), but I think that it's a good idea after all.



But it bring some problems, for no reason each post (even the shortests ones like this) take almost 2 seconds to load. I think it's something about the new method of MarkDown parse that I'm using. Need to test it out.

After this session I will publish this "website" thus I can show for people easily

-----------

Another cool thing is that, if I didn't add cover image for the post, it will generate one. For now it still just an `<h1>`, but i will create more diversed things in the future. 

New Blog Features


So, I'm starting this new projetct, a blog to post articles about game development and architecture. Thus I need a web site to post it. The first option would be to use Medium. But I'm a web developer, so I need to try to create my onw!

After 2 days fighting with CSS I reach a very simple grid template with a markDown parser to help the writting.

And everything was *almost* responsive, at least I tried to make it so.



![first-version](first-version.gif)

Another important thing, english is not my main language, so maybe I gonna write wrong some things.

I will comeback latter to talk a little more about the company and the ideas behind it, but for now this is the first post ever :)

