Faz certo tempo que penso em voltar a criar sistemas para uso pessoal. Não por portfólio ou motivos comerciais ocultos, unicamente sito falta de pensar em como usar o que eu sei fazer para desenvolver algo que me seja útil no cotidiano, solucionando incômodos insistentes que vou aguentando e varrendo para debaixo do tapete.

Por isso olhei para meus hobbies. Quando não trabalho, divido meu tempo entre leitura, animes, jogos, música e culinária. Tenho lacunas em todos, mas atualmente um deles me incomoda bastante, principalmente por faltar uma ferramenta que seja aceitável para uso corriqueiro quando a escala acontece. É o caso do último da lista.

Cadernos de receitas eu sempre tive e mantenho, é com ele que tudo começa, no analógico. Mas buscar uma receita nele quando eu preciso nem sempre é fácil, principalmente por causa da perda dos mesmos ao estarem totalmente rabiscados, para liberar o pouco espaço físico disponível. Passei por documentos de texto, tanto locais quanto em nuvem, depois compilei coisas em LaTeX e plataformas de receitas testei aos montes. Ainda assim me faltava algo que nenhuma tentativa supriu.

A experiência do caderno de receita físico ainda parece superior, mas a indexação é um problema após anos de armazenamento. Soma-se a isso as alterações e observações que vez ou outra faço em blocos de notas, pensando em futuramente passar a limpo, mas que no fim iam para o saco de reciclagem no meio de tantos outros papéis que utilizo diariamente.

Por isso decidi que voltaria ao desenvolvimento individual com o projeto de um sistema para simular meus cadernos de receita, tentando traduzir a experiência deles para uma estrutura de fácil indexação e disponibilidade. O que está registrado abaixo é o diário de bordo desta empreitada, um registro temporal de como as coisas se desenvolveram da concepção até o lançamento. É história viva, que espero ser pelo menos interessante acompanhar, sobretudo os intervalos marcados entre cada momento. Te espero na finalização.

[21/03/2026] Marco de início e proposta

Após um tempo refletindo, cheguei a conclusão que não sou uma pessoa que se empolga muito com as próprias atividades recreativas. Mesmo que tenha certa seriedade ao começar algo, geralmente não chego a colocar muito esforço para desenvolver cada vez mais alguma habilidade. Em alguns casos até mesmo deixo de lado algo que gosto bastante, mas que a inércia do cotidiano acaba por minar minha vontade.

Bom, tudo isto apenas como introdução para um projeto inicialmente despretensioso e que já existem aos milhares: um Caderno de Receitas (nome provisório). Culinária é algo que me atrai, mas não sou do tipo que se envolve para aperfeiçoar cada vez mais uma receita ou conjunto de técnicas, apenas gosto de comer coisas que me agradam. Se soa displicente para alguns, prefiro não me importar.

Mako Kawai de Food for The Soul

Para além de um simples registro, penso no Caderno de Receitas (nome provisório) como uma extensão do indivíduo, um artefato da sua história enquanto praticava sua atividade. Ingredientes e instruções como injunções simples não representam o significado da existência do caderno de receita. Este carrega notas, tentativas, erros, acertos e impressões, o que confere para ele uma alma que transborda de memórias.

Todas as aplicações online que encontrei falham em me proporcionar algo minimamente aceitável quando comparo com meus cadernos físicos. O problema não é o veículo, mas a tratativa de que a única coisa que importa é a receita, o resultado final com sua ordenação fria e aparentemente desprovida de improvisação ou imprecisões. Por isso resolvi criar o meu próprio Caderno de Receitas (nome provisório).

Marcille Donato de Dungeon Meshi

Claro que por ser uma aplicação comum, o primeiro questionamento que surge é: por que chover no molhado e não se adaptar para uma ferramenta que já existe? É um pensamento válido e suficiente para ceifar qualquer projeto comercial. O caso é que não quero lançar um SaaS, mas utilizar meu próprio conhecimento para fazer algo customizado e que resolva problemas pessoais que não estou disposto a adaptar ou ignorar para me encaixar no que está disponível.

Por não se tratar de uma proposta comercial, o Caderno de Receitas (nome provisório) tem seu marco de início neste dia. Tenho uma vaga ideia do conjunto de ferramentas que utilizarei, mas nada está escrito na pedra e nem considero isto importante agora (mesmo que no repositório inicial deste projeto exista um esboço). Concentrarei meus esforços daqui em diante na construção de um racional que faça sentido, passando por modelagem, especificações, arquitetura, desenvolvimento, teste e disponibilização.

Confesso que a única coisa que um pouco me preocupa é o tempo que levarei para chegar em um produto minimamente aceitável. Isto não por causa da complexidade, mas pela tribulação que se apresenta no horizonte de 2026. Não sei ao certo quantas horas ou dias poderei me dedicar ao desenvolvimento e registro do projeto. Existe muita incerteza e por mais que eu tenha vontade de fazer acontecer, nem sempre a realidade ajuda. Mas sinceramente, já me torturei em excesso com prazos, por isso farei deste retorno aos projetos pessoais uma ode ao processo. Chegou o momento de me divertir criando, característica que perdi ao longo dos anos.

[08/04/2026] Modelo e diferencial

O senso comum pondera que o mais importante para a criação de um software seja a tecnologia. Esta é necessária, mas não suficiente. Compreender isso é um passo crucial para o desenvolvimento de um sistema. Claro que o conjunto de ferramentas é algo importante, pode delimitar o tipo de funcionalidade ou a facilidade de implementação. Porém, cenários onde o kit de desenvolvimento importa são restrições de negócio, que nem sempre são existentes.

Dito isto, antes de pensar na tecnologia, abracemos o diferencial. Como comentado anteriormente, aplicações para registro de receitas existem em demasia, de modo que criar um novo sistema para isso seria improdutivo. Por isso primeiro utilizei o que estava disponível.

Verifiquei no cotidiano como é o processo de cadastrar, buscar e gerenciar as receitas. Trata-se de um uso ativo que supera o discricionário e busca adaptar a minha forma particular de lidar com a culinária, utilizando todas as funcionalidades existentes em cada plataforma. Simplificadamente, este é o primeiro passo da produção tecnológica: encontrar lacunas.

Saber, Shirou Emiya e Rin Toosaka de Today's Menu for the Emiya Family

Não vou ter o rigor da academia aqui, então vamos direto ao ponto: as plataformas seguem a ideia de redes sociais. Receitas são postagens que recebem curtidas e comentários, sendo a sua conta uma vitrine para exibir suas façanhas. Do início ao fim, impera a lógica do engajamento, mas não é isso que eu busco.

O caderno de receitas que eu quero é pessoal, uma relação íntima entre mim e a culinária. Não quero curtidas, nem comentários reforçando sucesso ou engajando pelo ódio. Ainda, o caderno que eu uso é cheio de notas que registram as diversas tentativas, erros e acertos, que correspondem a jornada pessoal desde o primeiro contato com aquela receita até o momento em que finalmente ela foi realizada com sucesso. Isto colide com a visão puramente injuntiva que existe.

Percebe que existe uma insatisfação com os produtos disponíveis? Há uma lacuna na minha forma de lidar com a culinária, que pode ou não ser compartilhada por outras pessoas. É aqui que se encontra o elemento mais importante do desenvolvimento de sistemas: identificar que falta alguma coisa e que este algo pode se tornar um diferencial que justifique o tempo gasto com a criação.

Desenvolver este caderno de receitas não pode ser uma tarefa discricionária. O sistema precisa transmitir proximidade e intimismo, rejeitando a estrutura de redes sociais e abraçando a linguagem da evolução e das sensações qualitativas, que implica no processo de erros e acertos que são inerentes de uma atividade puramente experimental.

Kuro e Alleta de Restaurant to Another World

Deste desejo surge a singularidade do projeto: tentativas. O caderno de receitas não é simples injunção, é história. Ele carrega notas de execução, que são as falhas até o sucesso. Isto deve ser central no modelo de dados do sistema, pois é tal abordagem que transforma a proposta de algo genérico em um produto no mínimo interessante.

Ainda, no caderno de receitas não atribuímos pontuação, tampouco likes. Essa estrutura de ranqueamento e numeração é perversa, se me permite o desabafo. Como é possível dizer que um Bolo de Milho é nota 3,5 e um outro é 4,3? Traduzir algo qualitativo em uma escala quantificada, totalmente arbitrária e de interpretação difusa para cada indivíduo, é talvez um dos piores atrasos que a sociedade moderna normalizou. Compras, comida, transporte ou relacionamentos, tal simplificação sublima a capacidade de abstração humana. Mas é extremamente útil para mineração de dados e outras modelagens das Big Techs.

Dito isto, o modelo deve rejeitar a estrutura de redes, propondo uma nova forma de interação que retome a subjetividade do indivíduo. Assim surgem as sensações. Quando escrevemos no caderno de receitas, o sabor se funde com a lembrança do dia, de modo que ao comer um biscoito não se sente o gosto do leite ou amido, mas sim aquele associado a uma certa tarde de silêncio, na qual era exibido um curto documentário sobre um pássaro capaz de imitar sons que escuta, desde naturais até buzinas de carro. Específico? Pois é exatamente este o ponto. Estas experiências não podem ser quantificadas, são emoções que carregam mais informações que a lista de ingredientes ou modo de preparo.

Por isso não serão utilizadas pontuações, apenas sensações. Elas se tornarão etiquetas que traduzem os sentimentos da pessoa, sem o compromisso de constituir hierarquia entre si. Certamente não é a melhor decisão seguindo os padrões de design modernos, focados na simplicidade e minimalismo. Talvez isso deixe a barreira de entrada para novos usuários maior, reduzindo o potencial de engajamento. Mas sinceramente, este projeto é um refúgio, não uma tentativa de criar um SaaS altamente lucrativo.

Rin Shima de Yuru Camp

Com isto os dois diferenciais do modelo proposto foram explicados e ainda sequer começamos a falar de tecnologia. Foi proposital. Por mais que meu tom seja intimista e um tanto abstrato, este caminho de refletir antes da ação leva a maior emancipação da ideia, com supressão da ansiedade do resultado. Em tempos de fear of missing out empurrado como normal pelas redes sociais, gastar tempo no processo é uma forma de rebeldia.

[05/06/2026] Descritivo de funcionalidades

Tenho a sensação de que o tempo passou mais rápido do que eu imaginava. Projetos pessoais acontecem dessa forma, mas isto não significa que nada foi executado. Após definir a filosofia do sistema, junto dos modelos básicos, inicia-se a parte mais chata da Engenharia de Software: documentação de requisitos.

Descrever funcionalidades do sistema é algo entediante, leva tempo e precisa ser feito com certa atenção para garantir que a execução do projeto ocorra sem grandes surpresas ou improvisações quiméricas. O planejamento muitas vezes é ignorado nos projetos pessoais, justamente porque o idealizador se confunde com o programador. Talvez este seja o motivo para muitos fracassos, mas não tenho como delimitar um experimento para avaliar isso, então melhor deixar de lado.

Karyl de Princess Connect

Desenvolver um software não difere muito da construção de coisas físicas, como peças, estruturas e casas. A ideia surge, pensamos no que gostaríamos e depois elaboramos um guia para que aquilo existente na nossa mente possa se tornar realidade. Um programa de computador segue o mesmo fluxo, o que muda é a nomenclatura e o conteúdo dos documentos de projeto. Se na engenharia há a planta, aqui temos especificações e arquitetura.

Mesmo um projeto pessoal, cuja concepção e execução pairam sob o mesmo indivíduo, negligenciar o planejamento vai gerar uma execução esquisita, cheia de improvisos. Isto acontece porque o cotidiano de todos, eu incluso, é repleto de tarefas diversas, pendências de atividades passadas e muitas vezes incêndios do trabalho ou da vida pessoal. Por isso confiar na memória para desenvolver algo é uma péssima ideia.

Documentar é uma carta de amor que você envia para a sua versão de si no futuro. Poesia de lado, intermitências são comuns em projetos comerciais, quem dirá nos pessoais, que geralmente sofrem com a falta de tempo ou com o cansaço após dias de trabalho. Transformar a ideia abstrata em requisitos funcionais práticos garante que toda essa conversa espirituosa da concepção não se perca durante a implementação.

Marcille Donato de Dungeon Meshi

Operacionalizar deve ser uma função técnica, na qual não nos perguntamos, para cada funcionalidade, quais são as regras, validações, permissões e comportamentos. Tudo isto deve estar definido porque cada pequena ação integra o todo, que garante a usabilidade do sistema pelo usuário. Improvisar na execução é perder a noção de integração, essencial para que o software seja minimamente funcional.

Consegui te convencer sobre a importância da documentação? Espero que sim. Mas antes de avançar para o trabalho, será que lhe chama atenção que até agora, depois de tanto texto, nada foi falado sobre tecnologias adotadas? Foi intencional, porque até a confecção dos requisitos o software é agnóstico em relação ao tipo de ferramenta para desenvolvimento. Linguagens de programação, frameworks e afins serão discutidos apenas na arquitetura, a próxima etapa.

Agora, depois de longos 7 parágrafos, sigamos para o tema central, juro que sem mais enrolação. Criar especificações começa ao se pensar na jornada do usuário, no que ele precisa fazer dentro do sistema. Para cada ação surgem uma ou mais funcionalidades, que se complementam. Isto é, não existe ação do sistema que faça mais do que é preciso, a ideia é reaproveitar.

Kuro e Alleta de Restaurant to Another World

A primeira ação do usuário é gerenciar sua conta, o que inclui os processos de criação, recuperação de senha, edição dos dados de perfil pessoal, atribuição de um avatar e a autenticação no sistema. Esta última é especial, pois é dela que o resto as dependem. Excetuando a criação e recuperação, todas as atividades precisam ser protegidas pela autenticação, que garante a validade da solicitação do usuário. Mesmo que pareça óbvio é preciso que esteja escrito explicitamente em todas as especificações. Eu não menti quando disse que é uma atividade entendiante.

Antes de comentar sobre a receita, uma das diferenciações discutidas anteriormente é a tradução da classificação qualitativa, que substituirá notas, estrelas e qualquer outro tipo de estrutura gamificada. Dando o nome de Sensação, cada usuário precisa ver, criar, editar e excluir esses registros. Importante que o dado de sensação seja sempre uma instância de nome e descrição, que incentive a pessoa no sentido de criar uma semântica própria para customizar a sua experiência.

Para as receitas, o básico é listar todas as existentes para o usuário autenticado e permitir criar novas. A criação precisa ser simplificada com nome e breve descrição para que uma listagem simples seja eficiente para a pessoa diferenciar todo o conteúdo que cadastrou. Porém, ao acessar uma receita específica será preciso exibir o modo de preparo, ingredientes, imagens existentes, situação da replicação (enumeradores para aprovada, em ajuste ou reprovada), sensações relacionadas e por fim todas as tentativas de execução realizadas.

Situação e modo de preparo precisam ser editáveis, são ações que o usuário atualiza de acordo com o desenvolvimento da própria receita. As imagens existentes podem ser removidas e novas podem ser enviadas. O mesmo acontece para ingredientes, com possibilidade de criar e remover. Sensações seguem uma lógica semelhante, porém a ideia é atribuir já existentes ou remover relações criadas entre receita e sensação.

Falando sobre tentativas, para cada receita é possível criar, editar, anexar fotos e remover registros dessas instâncias. Elas funcionam como o histórico das execuções e evolução da receita, desde a primeira versão até o ajuste final. Para manter a ideia de progressão, enumeradores servem de rótulo e o texto livre permite a personalização das notas.

Yuuki, Karyl, Pecorine e Kokkoro de Princess Connect

As demais funcionalidades são auxiliares, começando pela busca. O dono pode marcar uma receita como pública, o que permite ela ser encontrada por outros usuários, capazes apenas de visualizar os dados relacionados, sem poder de edição. Entretanto, uma receita pública pode receber sensações de usuários diferentes do criador, algo que inclui interação sutil entre membros do sistema.

Também pensando em interações entre membros, dada a identificação interna de um usuário, deve ser possível recuperar receitas públicas cadastradas por ele e informações básicas como nome e avatar. Isto é o suficiente para compor uma página de apresentação pessoal, sem expor dados e informações pessoais. Esta ponderação deve ser registrada como imperativa, ou seja, que nenhum usuário autenticado consiga ver informações sensíveis, como e-mail cadastrado, de outro usuário.

Para finalizar as interações, um usuário pode criar listas de favorito, bem como editá-las e removê-las. Nelas é possível realizar a anexação de receitas públicas descobertas pela busca, algo que garante organização e persistência de conhecimento entre usuários que marcaram publicidade dos registros.

Pelo lado do sistema, totalmente invisível ao usuário, logs devem ser registrados para toda requisição no intuito de manter auditoria, identificar tráfego robótico, avaliar carga do servidor e metrificar uso das diferentes funções disponíveis, que pode sustentar testes A/B futuros. E claro, retomando, por definição todas as ações devem ser protegidas por validação de autenticação, até mesmo o acesso de receitas nomeadas como públicas.

Rin Takanashi de The Forsaken Saintess and her Foodie Roadtrip in Another World

Para as pessoas da área esta descrição foi simplista. Já para não programadores pode soar estranha. De todo modo, escolhi deixar aqui uma visão panorâmica sobre o assunto, um pequeno diário de bordo. Os documentos técnicos de especificação se encontram no repositório do projeto, junto do código-fonte e outros artefatos de desenvolvimento. O endereço de acesso está ao final deste relato, mas ainda faltam alguns passos para chegar lá.

[09/06/2026] Documento de arquitetura e design

Tentarei ser objetivo, pois depois de tanto alongar sobre temas mais abstratos é preciso comentar tecnologia, interface e experiência de usuário. Feitas as especificações e requisitos, o último passo do planejamento é arquitetura e design, elementos, confesso, mais atraentes, pois neste momento o desenvolvimento começa a tomar contornos de software.

Rin Toosaka de Today's Menu for the Emiya Family

Para escolher o conjunto de ferramentas, é importante pensar nas particularidades de utilização. Considerando que não existe necessidade de SEO e esta aplicação pode evoluir para uma versão mobile nativa, é de bom tom não tratar o desenvolvimento como full-stack monolítico. Traduzindo, padrão API REST para o servidor, responsável por toda a lógica pesada de dados, enquanto o cliente em SPA cuida de renderizar a interface.

Pensando em simplicidade de disponibilização, PHP apresenta implementação quase inevitável, executando em servidor Apache com pouquíssimo custo de infraestrutura. Ainda, considerando que este projeto não é complexo, tem-se um ótimo trade-off ao trazer tal stack porque é rápido de desenvolver e o código fica limpo para revisar e dar manutenção. Neste cenário, o Laravel se torna uma boa opção por possuir um amplo conjunto de soluções compactas para migrations, testes automatizados, gestão de arquivos, integração com login social, autenticação e outros que forem necessários.

Sobre a gestão de arquivos, é possível construir acessos públicos ou privados via middleware de autenticação Sanctum. Para o caso deste projeto, considerando que são apenas fotos de receitas, não há problema em tornar estes arquivos públicos via estáticos, o que facilita as regras de implementação e disponibilização. Sempre é bom optar pelo mais simples, princípio de Ockham.

Sobre autenticação, diversos conjuntos estão disponíveis, mas a escolha ideal é o Breeze no modo API. Vou justificar. Frente outras opções, como Jetstream, Fortify ou Passport a resposta é simples: over engineering. Estamos lidando com API REST, que processará tokens CSRF ou JWT, além de ser um projeto pequeno e que, no máximo, precisará de login social futuramente. Neste cenário, o Breeze resolve muito bem e conversa sem problemas com o Socialite, que permite utilizar outros provedores de identidade, como Google, por exemplo.

Shinon Ogawa e Mako Kawai de Food for The Soul

Por fim, banco de dados. Sinceramente, neste nível em que estamos, factualmente não há diferente entre os relacionais existentes. Fato apenas que um não relacional (NoSQL) seria arrumar problema, os dados possuem relações fortes entre si. Este tipo de banco possui mais aplicabilidade em sistemas temporais e industriais, o que não é o caso aqui. Voltando, a escolha neste projeto é quase preferência pessoal e quando trabalho com PHP gosto de trazer o MariaDB, por isso ele será o escolhido.

Na organização de código, sem muito o que inventar utilizando o padrão de camadas para isolar validações de entrada, serviços especializados e processamento dos modelos de dados. Esquece DDD ou outra coisa mais complexa, não vale a pena. E se você que lê pensar em microsserviços, busque tratamento psiquiátrico. Isto fecha o lado do servidor, sigamos para aquilo que o usuário vê.

Criar interface puramente com HMTL, CSS e JS, tal qual fiz no início dos anos 2000, acreditando que Bootstrap e WordPress eram revolucionários, não funciona atualmente. Seja complexidade, tempo disponível ou reaproveitamento de código, por mais que a proposta deste projeto seja simples (repetirei isso muitas vezes), ele pecaria em manutenibilidade ou atualizações de funcionalidades. Templates podem ser mais limpos e reutilizáveis, mas seria colocar mais carga no servidor além da lógica. Deixe o cliente resolver a interface, transferência de responsabilidade e redução de custo, por isso SPA é interessante.

Dentre os frameworks SPA disponíveis, para este tipo de aplicação, não há grande diferença. Considerando a minha familiaridade e a amplitude dos casos de uso, a escolha fica com o React. Sobre padrões de design, daisyUI disponibiliza prontos diversos componentes comuns de UI, junto de variados temas que podem ser aproveitados e customizados, o que acelera ainda a criação das páginas e mantêm consistência visual.

E claro, sei que este conjunto de React, Tailwind e daisyUI é um pouco problemático em hardwares modestos (para não dizer antigos), mas ainda assim é um trade-off aceitável, pois a maior parte da interface é composta por formulários e exibição de texto, com poucas animações ou outras ações que requisitam processamento. Por enquanto, sigamos com ela.

Com a interface construída separadamente, o build gera os estáticos (HTML, CSS e JS) da aplicação, que serão servidos via Laravel ao cliente por uma única rota. Isto significa ajustar o sistema de redirecionamento do Apache, enviando todas as requisições /api para a API REST e as demais para a porta de entrada do React, que cuidará do roteamento interno SPA.

Outros documentos de arquitetura disponíveis no repositório detalham o que foi discutido, especificando modos de trabalho com datas, padronizações de schemas JSON das respostas, articulação das camadas da API e requisitos mínimos de testes automatizados. São arquivos puramente injuntivos para servirem como guia de execução, no intuito de ter códigos organizados e facilmente lidos. Sobre infraestrutura, um Docker Compose para desenvolvimento com hot reload e outro para deploy, discutido no final.

Marcille Donato de Dungeon Meshi

Superada a parte técnica, chegamos ao momento de decisões visuais, sendo a primeira delas o nome. Recordo que Caderno de Receitas é apenas um termo provisório, dado no início do projeto e que resultou na nomenclatura genérica do repositório. Mas este projeto ganhou nome próprio, que devo explicar racionalmente a escolha feita de forma certamente irracional pela minha mente.

Desde a concepção da ideia, a personagem Marcille de Dungeon Meshi aparecia como assombração quando pensava neste projeto. A explicação desconheço e nem entrarei nos delírios psicanalíticos para buscar uma interpretação quase exotérica do subconsciente. Então desisti de afastar e insistente lembrança para utilizá-la como base.

Ela é uma maga, livros e grimórios fazem parte da sua composição de personagem. Claro que nada relacionado com culinária, fora o fato de ser obrigada a comer coisas esquisitas na história, mas a ideia de magia é um bom ponto de partida. Chamar o caderno de grimório soa interessante, pois remete ao místico que encerra conhecimentos arcanos. Mas o nome do lugar ainda precisa trazer a sensação de tentativa e experimentação.

Além dos livros, uma imagem clássica da feiticeira é uma sala cheia de frascos com ingredientes e um caldeirão de fabricação para poções e outros insumos mágicos. O caminho é por ai, mas caldeirão não era a palavra adequada, para mim remete a feijão e o dourado dos cabelos da personagem me recorda o caramelo do doce de leite, feito no tacho.

O caminho foi mais ou menos esse para se chegar ao nome Tacho Arcano. Com licenças poéticas ou não por parte da minha memória, a plataforma ganha sua designação e também o direcionamento de tom. Pergaminhos em uma sala cheia de registros históricos das diversas tentativas feitas naquele caldeirão borbulhante, algumas bem sucedidas e outras nem tanto.

Para compor a paleta continuei com a Marcille em mente. Do seu design extraí as principais cores: dourado, verde e azul. Dada a ideia de pergaminho, não existe possibilidade da cor de fundo ser branca, precisa remeter aquele pepel amarelado, por isso adaptei o dourado até chegar no resultado desejado. Também o azul e o verde passaram por ajustes para serem mais frios, sendo apenas o dourado aquele de destaque. Eis o tom final.

Aos profissionais de design peço perdão após esta pequena patifaria tentando descrever o processo de decisão com termos mais vagos. É preciso lembrar que sou um engenheiro de software acostumado a escrever código, estruturar planos e lidar com demandas materiais bem definidas. Da concepção de interfaces, metodologias formais de criação, escolha tipográfica e teoria de cores sei pouco, por isso me apeguei a algo pronto e desenvolvi sobre, na tentativa de criar uma estrutura minimamente coerente.

Alleta de Restaurant to Another World

Com isto contemplo os principais pontos sobre arquitetura e design. Não há mais necessidade de alongar esta seção, dado que para quem desejar os documentos completos estão no repositório aberto. O planejamento acabou, vamos ao processo de codificação e construção do recém nomeado Tacho Arcano.

[11/06/2026] Desenvolvimento da API

Codificar é um processo operacional, que traduz em linguagem de programação as descrições de cada especificação, seguindo a arquitetura e padrão de design adotados. Sabendo-se o que fazer e o que testar, basta escrever. Diferente do imaginário comum, grande parte do trabalho está na definição antes do código, dominando os conceitos, modelagem e padrão de projeto.

Hoje é possível automatizar grande parte do trabalho mecânico, o que resolvi fazer neste projeto para testar o desempenho do GLM 5.2 e o quanto facilitaria a minha vida em suprimir a famosa repetição de CRUD que aqui se apresenta. Claro que o desafio do agente não é grande, reforcei por várias vezes a simplicidade técnica da aplicação, mas isso não torna o produto menos interessante, pois é a composição das funcionalidades que dá o diferencial, não o código.

Entretanto, a janela de contexto é algo que me preocupa e por isso é uma péssima ideia jogar todos os documentos de especificação e esperar que o agente resolva tudo. É preciso lembrar que, de modo bem grosseiro, estes modelos são completadores de texto, por isso quanto mais restrito o ambiente e a atividade, menor a chance de sair algo escabroso.

A abordagem da engenharia de software adotada é o desenvolvimento incremental atomizado, na qual a criação é vista como um quebra cabeça e cada peça ocupa o seu lugar, mas colocamos uma de cada vez. A estrutura geral foi definida manualmente, sendo ela composta pelo formato do Laravel, codificação dos modelos de dados na primeira migration, infraestrutura Docker de desenvolvimento e teste, sequenciamento de endpoints, separação da camada de serviço e instalação dos pacotes fundamentais.

Rin Takanashi de The Forsaken Saintess and her Foodie Roadtrip in Another World

Desta forma a função do agente se torna direta: preencher controllers e models para cada conjunto de funcionalidades na sequência posta. Assim que um grupo de especificações é finalizado, o mesmo é documentado em OpenAPI e journal estilo wiki. Enquanto aquele serve de documento formal para humanos, este tem como principal função servir de memória para os próximos passos do agente.

Em outras palavras, a cada iteração o agente implementa apenas tarefas atomizadas e, quando funcionalidades se cruzam, consulta a wiki e acessa exatamente o local necessário. A ideia é essa, apesar da execução ser um pouco turbulenta. Com esta abordagem se tem o suficiente para garantir qualidade, restringindo o papel do agente a completar as lacunas de cada endpoint e seu respectivo conjunto de testes automatizados, por assim dizer.

Dito isto, construção sem maiores problemas e dentro da arquitetura desejada, com código de fácil leitura. Minha revisão não identificou problemas e devo dizer que me surpreendi, principalmente com os devidos casts na camada de modelos, que garante replicabilidade e consistência relacional dos dados, protegendo informações sensíveis dos usuários. As permissões também foram seguidas e implementadas corretamente.

Confesso que eu esperava algum tipo de engasgo com autenticações, validações e permissões, mas não ocorreu. Sem cair em falsa humildade, a documentação foi detalhada e precisa ao ponto de um programador minimamente conhecedor da linguagem conseguir executar os passos da implementação sem ocorrer em dúvidas.

Falta comentar sobre dois últimos assuntos, que finalizam a construção da API. O primeiro envolve testes automatizados, que foram totalmente executados e sem necessidade de ajuste. O sistema de teste do Laravel, PHPUnit, é competente e com regras bem definidas nos documentos, sem muitas políticas complexas, o GLM 5.2 não encontrou qualquer problema.

O segundo caso é sobre o login social, que não implementei nesta versão unicamente porque ainda não criei um projeto na GCP para lidar com aplicações pessoais. Como não irei, e nem devo, misturar os ambientes de disponibilização pública e comercial, apenas quando terminar de organizar a arquitetura para sistemas abertos é que voltarei para integrar o Tacho ao Google e talvez outros provedores de identidade.

[13/06/2026] Executando o agente para a UI

O fluxo de iteração para a UI segue uma filosofia análoga ao caso da API, adaptando-se ao trabalho com interfaces que consomem dados de um serviço externo e com isto modifica o próprio estado. As etapas de desenvolvimento seguem: codificação dos serviços de acesso à API; estruturação das rotas protegidas; alocação de componentes reutilizáveis (tabelas, cartões e outros) e implementação das páginas descritas nas especificações.

Não me alongarei neste ponto. Dado que o React é um framework altamente popular e isto gera muito material de referência, o GLM 5.2 implementou o fluxo rapidamente e relativamente funcional, dentro da arquitetura proposta. Porém nesta tarefa os engasgos foram maiores.

Karyl de Princess Connect

O principal problema se deu com código bagunçado. E sim, sei que exigir de JS limpeza não é algo muito honesto, o negócio foi criado para fazer maracutaia, mas mesmo assim a legibilidade inicial não foi das melhores. Felizmente ao seguir a arquitetura de separação o problema se concentrou nas páginas, enquanto todo o resto até ali foi bem organizado. Isto significa que para a UI as especificações técnicas das páginas devem ser mais detalhadas do que o apresentado inicialmente. Um desenvolvedor humano, por mais iniciante que seja, conseguiria transformar a documentação existente em interfaces minimamente organizadas, porém para um agente de código a inferência foi fraca. Fica de aprendizado para os próximos.

Outro ponto problemático foi relacionado ao design. A paleta proposta foi seguida, porém com hardcoded de CSS em cada elemento. Isto é, sem medo de soar alarmista, um furo tenebroso. Qualquer alteração de cores implica em caçar por todas as páginas, por todo o HTML, onde os estilos estão e realizar a troca. Mais uma vez algo interessante, porque esta boa prática de manter uma folha de CSS global com configurações e variáveis reutilizáveis não foi documentada, porém qualquer desenvolvedor frontend minimamente competente sabe que isto deve ser feito.

Como gosto de comparar, agentes de código são a grosso modo completadores de texto. Quanto melhor a base fornecida, mais preciso é o resultado porque a inferência fica restrita a algo que não solicita raciocinar, apenas implementar. Ao não prover o mesmo contexto e orientações nos documentos da interface, quando comparados com os da API, deixei lacunas que foram preenchidas por indução geral. Outro aprendizado anotado.

Corrigir não foi algo complicado, com mais informações o GLM 5.2 foi capaz de fazer a limpeza estruturada do projeto da interface, deixando as devidas funções, componentes, páginas e estilos com alta legibilidade para humanos. A nível de código o resultado foi satisfatório, mas eis o momento da prova de fogo: a análise de UX.

[17/06/2026] Análise UX

Em projetos pequenos que seguem todos os ritos de idealização, planejamento e desenvolvimento, bugs não são muito comuns, sobretudo pela boa cobertura de validações e documentações. Entretanto, o uso corrente coloca aquilo que foi imaginado à prova. A famosa etapa de qualidade é que garante funcionalidades em pé e, principalmente, usabilidade confortável para o usuário.

Experiência de usuário é algo subjetivo, não é possível transformar em um checklist de elementos a implementar que funciona como bala de prata. Definir o termo confortável é complexo, por isso o caminho aqui é usar e registrar as interações entre indivíduo e sistema. Como se dá o processo de cadastrar uma nova receita? O que é utilizado e o que não é? Existe algo confuso? O tempo de resposta é adequado? Falta feedback visual de processamento ou erros? Estas são algumas das perguntas possíveis, mas nem de longe são exaustivas.

Rin Shima de Yuru Camp

Obviamente que o máximo possível para mim é tentar ser extremamente crítico no teste de uso, simulando um usuário comum que acaba de conhecer o sistema. Louvável, mas impossível. Eu conheço cada modelo de dado e interações existentes, por isso viés vai acompanhar toda e qualquer observação que eu fizer. Para um projeto pessoal e isolado é fundamental aceitar que ele está incompleto e cheio de lacunas que apenas a utilização por terceiros pode revelar.

Em questão de interface, daisyUI e Tailwind mantiveram a harmonia do sistema, o que resultou em navegação sem problemas aparentes e consistência de elementos visuais sem quebras de layout. A localização das áreas também não apresentou problema e a responsividade entre dispositivos funcionou.

O primeiro caso de experiência estranha se deu por causa da modelagem proposta para a receita, que não é uma tabela única e sim uma instância básica com relações que armazenam ingredientes, tentativas e imagens. Provavelmente os sites existentes fazem a mesma abordagem de dados, porém na interface colocam uma página única com todas as informações e criam um endpoint especializado em criar, a partir de um grande formulário, todas as instâncias necessárias.

Eu simplesmente não gosto desta solução, faz com que existam funções extremamente complexas na API, sem falar na necessidade de garantir atomicidade das transações com banco de dados. Para sistemas complexos isso às vezes é inevitável, mas em uma simples aplicação de cadastro e gestão de receitas se torna apenas lotar, tanto servidor quanto usuário, de informações que poderiam ser perfeitamente isoladas.

O modelo estava preparado para receber valores nulo em certos campos, porém a interface criada tinha um fluxo diferente, sobretudo na criação da instância básica de receita. Era preciso dar o nome, a descrição e o modo de preparo em texto, antes de chegar na tela de edição. Isto é contraintuitivo, o normal quando se testa uma receita é no máximo colocar o nome, depois ingredientes, modo de preparo e então tentativas.

A solução foi à nível de interface, reduzindo o cadastro de nova receita para apenas o nome, sendo todos os outros campos nulos e editáveis via tela de edição. Nesta há separação por áreas para organizar as diferentes informações da receita e assim permitir ao usuário cadastrar, de acordo com o fluxo que lhe couber, ingredientes, modo de preparo, imagens e tentativas. Ganha-se descentralização, sem dependência de um único formulário gigante para qualquer ajuste, que permite a interação unicamente com o elemento necessário durante o uso do sistema.

Dado que foi uma questão de usabilidade e não de lacuna nos modelos de dados, não foi necessário ajuste da API para alterar tal dinâmica. Fica então o bom exemplo de modelagem robusta e pensada, pois entrega flexibilidade para a interface implementar diferentes jornadas sem retrabalho para o servidor. Também advoga a favor de endpoints especializados e simples, sem encadeamentos ou all in one, para que ajustes de tela não impliquem em retrabalho na lógica do sistema.

A segunda interação problemática se deu na parte de descobrimento. A busca por receitas públicas permite encontrar algo pelo nome, mas e se o usuário não tiver exatamente certeza daquilo que deseja? Este caso é o de alguém que olha vitrine, ou seja, observa aquilo que está disponível até achar algo que lhe chama atenção. No planejamento inicial existia a possibilidade de busca, mas não a visão ativa de todo o conteúdo do sistema.

Rin Takanashi de The Forsaken Saintness and Her Foodie Roadtrip in Another World

Esta é uma nova funcionalidade, portanto não há alternativa: será preciso modificar a API. Felizmente não é algo de grande complexidade, sendo até mais simples que o endpoint de busca existente. A paginação é o ponto mais importante, deixando por definição a ordenação alfabética. Isto já é o suficiente para permitir que o usuário passeie pelos registros públicos existentes. E como toda a arquitetura está desacoplada e coberta por testes, executar o módulo do PHPUnit garante que nada, por azar, foi quebrado.

Com a API atualizada, a página de visualização não precisa inventar muito, visto que a visão de cartões já existente nas outras áreas, com nome e breve descrição da receita, funciona para a nova funcionalidade. Clicar em uma leva para a página de visualização pública, com tudo as informações básicas de replicação e também o histórico de evolução.

Outros ajustes foram pontuais, como tooltips descritivos, aumento ou redução de fonte em determinado cartão e opções de ordenação dos registros. Mesmo que se tratem de interações que impactam o uso cotidiano, ficaria moroso escrever detalhes aqui, além de transformar o texto em uma espécie de lista técnica ou relatório escolar. Sinto infelizmente que este predominou o tom da seção, mas não encontrei forma melhor de tratar sobre experiência de usuário sem recorrer ao relato.

[18/06/2026] Disponibilização pública

Um sistema sempre pode melhorar, mas apenas após o estresse do uso cotidiano. Antes disso, atrasar o lançamento é puro preciosismo covarde. Depois de seguir por todas as etapas descritas até aqui, o Tacho Arcano está pronto para ser servido publicamente para qualquer usuário que desejar acessar. A última atividade é ajustar o ambiente de produção.

Para este sistema, a lista de preparo para deploy consiste de três itens: ajuste do domínio, build do React e redirecionamento do Apache. Para o primeiro item, dado que o Laravel é a porta de entrada da aplicação, acessível via URL pública, o Sanctum precisa reconhecer o domínio que envia a requisição. Isto é facilmente resolvido com variáveis de ambiente e ajustes do sistema de configuração do Laravel, ou seja, não impacta código da lógica do sistema.

O segundo item requer um pouco mais de construção, mas é totalmente apartado do código fonte da aplicação, dado que o uso das variáveis de ambiente para evitar hardcode foi algo tomado como base desde o início. Para automatizar e padronizar, o Docker Compose de produção executa o build dentro do contêiner, evitando a necessidade de dependências no host. Ao final, copia os arquivos estáticos gerados para um diretório mapeado e compartilhado com o Apache.

Por fim, o terceiro item é de simplicidade extrema, sendo necessário apenas definir as regras de redirecionamento do Apache. Neste, todas as URLs com o sufixo /api servem o arquivo index.php que é responsável pela inicialização do Laravel. As demais requisições são enviadas para o index.html resultado do build executado pelo React, sendo que este resolve o roteamento no cliente para renderizar as páginas.

Kurea Furutachi, Mako Kawai e Shinon Ogawa de Food for The Soul

Feito isto, o sistema está pronto para acesso público através do domínio tachoarcano.silenciosescritos.com.br e isto marca a finalização do projeto. Antes de encerrar, preciso retomar o que disse ao abrir esta seção: existe espaço para melhorar. Após estas notas continuarei a utilizar e registrar bugs, melhorias de interface e novas funcionalidades. Entretanto, todas as atualizações seguirão apenas via repositório disponível aqui. Esta é a última descrição em texto do Tacho Arcano, então seguirei para minhas considerações finais.

[24/09/2026] Adeus e até a próxima

Muito tempo se passou. Foram três meses desde a finalização do Tacho Arcano, com longos dias que pareciam ser pouco produtivos. Em verdade, minha ideia era transformar as notas feitas durante o desenvolvimento em um texto único logo no mês de Julho, porém nem na minha pior estimativa eu consegui prever tantas intermitências.

De fato, apenas no início de Agosto consegui organizar as notas e iniciar o texto que se prolongou até aqui. A ideia era ser um diário técnico de desenvolvimento, no qual implementava algo e escrevia o resultado, mas o pouco tempo que tive pra desenvolver não deixou sobra para a escrita. Tentei depois transformar em algo mais trabalhado, mas no início de Setembro mudei completamente de ideia porque não só seria didatismo como chato. Por isso no final do mês joguei o que já tinha produzido no lixo e alterei o tom para algo mais intimista, que mescla computação com planejamento.

A caminhada não foi linear da forma que eu esperava, muitas coisas se sobrepuseram e no fim fiquei com a sensação de que não era exatamente o que eu queria entregar. Que seja, é hora de um ponto final e seguir para novas ideias. Na minha rotina o Tacho Arcano já ocupou seu espaço. Nem todos os meus registros antigos foram migrados, mas todos os novos foram criados nele e o sistema de tentativas foi excelente para manter o histórico dos erros e do que ajustar nas próximas, bem como expor dicas de execução para o meu eu do futuro que tentar replicar alguma receita depois de tempo sem fazê-la.

Rin Takanashi de The Forsaken Saintess and her Foodie Roadtrip in Another World

Ainda, não posso finalizar este relato sem comentar sobre o uso dos agentes. O Tacho Arcano foi o primeiro projeto em que utilizei esta ferramenta para criar todo o código, exceto o esqueleto base e o modelo de dados. Foi uma tentativa de adaptar as documentações comumente utilizadas para serem consumidas por GenAI que fazem o trabalho bruto de preencher o que falta.

Diferente do que muitos vibe coders acreditam, comandos simples não geram bons resultados, principalmente se a modelagem de dados for terceirizada. Se pelo menos o modelo utilizado estiver bem documentado, uma API Rest composta em maior parte de CRUD é desenvolvida sem grandes problemas. Para interfaces o buraco é mais embaixo, o que de fato é esperado.

Agentes geracionais não interpretam código, apenas replicam uma lógica prévia. Em outras palavras, dado um modelo de dados é possível que se crie o formulário completo, o botão de salvar e as funções que ligam API e interface, mas se esta página está equilibrada visualmente ou provê uma boa experiência isto depende de um humano para validar.

Ainda, independente do uso em backend ou frontend, desconhecimento da linguagem e frameworks adotados é receita para fracasso. Sem descrições claras e de nível técnico, desde arquitetura de software até a sintaxe e fluxo de execução do código, o agente cospe probabilidades que não refletem um produto. E não poderia ser diferente, pois é exatamente assim que a ferramenta funciona, são preditores estocásticos.

De todo modo, é inegável que para quem sabe o que está fazendo isto libera muito tempo do trabalho braçal e pouco cognitivo. Se em 11/06/2026 eu terminei as documentações, o desenvolvimento da API levaria pelo menos 1 mês, empurrando a finalização para Julho. Já a interface gastaria facilmente bem mais tempo porque é muito mais código para cada especificação, de modo que entre Agosto e Setembro eu poderia testar.

Yuuki, Pecorine, Karyl e Kokkoro de Princess Connect

Gastar tempo melhorando a ideia, os modelos de dados e os diferenciais é muito mais interessante do que ficar escrevendo CRUD. É naquela etapa que o trabalho cognitivo e empolgante se concentra, por isso ter mais tempo para refinar a proposta e rascunhar as possibilidades me deixou animado. Muitos projetos geralmente morrem na implementação por falta de espaço na agenda para uma atividade longa que pouco conseguimos ver avanço. E nessa luta pela sobrevivência, percalços são comuns e o tempo que pensávamos ter se esvai com facilidade.

Vejo com positividade ferramentas de IA, o único caso que me preocupa é a transmissão de conhecimento para os mais jovens. Já estou na área de programação faz 12 anos, passei por muitos perrengues com linguagem e suas mudanças arbitrárias. Estava lá no período de transição do Java Swing para o JavaFX. Tive minha cota de pesadelos com a primeira versão Android Studio, que me levou para ambientes tóxicos do Ionic com o aquele Cordova e posteriormente para o esquisitíssimo Xamarin (que Deus não o tenha). E o que falar da atualização do Angular 2? E aqueles node modules que comiam disco para fazer uma página com um botão? Quantas vezes mataram o PHP e esse zumbi insistiu em voltar?

Enfim, a história de um desenvolvedor está intimamente entrelaçada com o código e as diversas cabeçadas na parede para aprender algo novo, para logo em seguida descobrir algo melhor ou um jeito mais fácil. Faz parte do processo de aprendizagem pensar, implementar, errar, corrigir e melhorar. Para nós, um pouquinho mais velhos, que já passamos por essas experiências, nossa mentalidade está bem formada ao ponto dos agentes de código serem apenas ferramentas que facilitam trabalho repetitivo que nós sabemos fazer. Mas isto não é verdade para quem está começando.

Aprender implica em errar, mas o afã por ganhar tempo e produtividade impulsiona a adoção de ferramentas facilitadoras, que tornará muitos dos novatos dependentes de plataformas que desenvolverão as habilidades básicas de racionalizar um problema. Pensando nisso tentei ser menos técnico neste diário. Mesmo que provavelmente muitos daqueles que passem por aqui não pensem em desenvolver algo, pelo menos fica uma pequena contribuição de como o pensamento racional foi aplicado para a construção de alguma coisa.

Pecorine de Princess Connect

O que virá no futuro eu não sei, tampouco tentarei realizar previsão. Tenho nada além de achismo para isto e o foco deveria ser sobre o processo de desenvolvimento do Tacho Arcano. Por isso, em tempos de tanta mutabilidade e imprevisibilidade, deixarei o assunto no ar por enquanto e vou tentar ajustar a receita de canelé, que mesmo após tantas tentativas, não consegui fazer funcionar perfeitamente. Até a próxima.