Blog /
Lançado o Mynotes.space

Cléber

![Architecture: Ricardo Gomez Angel at Unsplash](/files/8) *Imagem: por Ricardo Gomez Angel em Unsplash.* ----- Está no ar meu mais novo *side project*. Há várias formas de se desenvolver software. Você pode codar orientado a escalabilidade, extensibilidade, facilidade de entendimento por parte das equipes, velocidade de execução ou qualquer outro objetivo ou mesmo uma soma de vários deles. E eu mesmo poderia escrever bastante a respeito do que considero "melhores práticas" de desenvolvimento de software. Todavia um dos aspectos mais curiosos do desenvolvimento desta nova plataforma acabou sendo justamente a ênfase diferenciada que dei durante o mesmo: coloquei em prática o que chamo de DOMPP: **Desenvolvimento Orientado à Mais Profunda Preguiça**. Explico. ### 1- A escolha do framework Inicialmente pensei em começar a desenvolver o projeto usando Django, que é o framework que tenho mais afinidade, atualmente. E até comecei do jeito tradicional: criei o projeto, configurei adequadamente o `settings.py`, criei algumas *apps*, escrevi os modelos principais... E então percebi que gastei um tempão sem chegar a lugar nenhum. Agora eu ainda teria que configurar uma API REST, escrever uma porção de *views*, definir uma forma de autenticação, escrever os testes unitários e por aí vai. E uma preguiça gigantesca foi surgindo só de pensar nisso tudo. Uma mistura de "*eu nem sei direito como vai ficar*" com "*também nem sei se vai ficar bom, no final*" já faz com que o Django seja um canhão muito grande para matar uma mosca. Mas não me entenda mal: **eu realmente gosto de trabalhar com Django**. Mas considero que para projetos "rápidos e rasteiros", ele ainda é burocrático demais. Lembro, inclusive, de uma "discussão perdida" em que alguém perguntou qual framework Web em Python seria melhor para iniciantes. Outro alguém respondeu "Django" e eu repliquei dizendo que não o recomendava para iniciantes. Ah, todo o restante quis me matar. Mas insisto na minha afirmação. Django é burocrático demais para um iniciante. Agora, para projetos em que espera-se um tempo de vida e de desenvolvimento longo, **eu absolutamente recomendo** o uso do Django. Mas, nesse momento e sob essas circunstâncias, A Preguiça precisava ser honrada e qualquer coisa muito burocrática acabou sendo deixada de lado. O framework escolhido acabou sendo, vejam só, o [LazyWF](https://github.com/cleberzavadniak/lazywf), "*the laziest web framework ever*". ### 2- O frontend De início pensei numa "arquitetura padrão" em que o backend provê uma API REST e o front é implementado em Javascript. Para isso, pensei em usar o [Riot.js](https://riot.js.org/), que é um framework bem simples mas que é poderoso o bastante para ser usado num projeto maior. E então crei um repositório para o frontend e comecei a criar alguns componentes com Riot. O problema, no entanto, começou quando percebi que é muito difícil, hoje em dia, continuar fingindo que Javascript não é uma linguagem **compilada**. Os tempos de simplesmente incluir um script na página HTML e sair criando componentes já se foi. E o que eu queria, ao frigir dos ovos, era escrever um frontend em **HTML, não em Javascript**. A solução, então, foi jogar tudo isso fora e criar uma aplicação à moda antiga, em que o backend responde às requisições do navegador cuspindo páginas HTML. **E isso tornou tudo TÃO profundamente mais divertido** que é difícil encontrar palavras para descrever. Eu reitero meu desgosto com o que a Web tem se tornado já tem muitos anos, mas admito que uma das formas mais interessantes de se escrever aplicações ainda é justamente fazendo com que a "GUI" seja composta por páginas HTML. Mas HTML tradicional, mesmo, com uso de tags "form" que enviam dados via POST, sem *xhr* nem nada parecido. ### 3- O renderizador de templates Inicialmente planejava não usar o `lazywf`, mas usar diretamente o `bottle` (um micro-framework Web que gosto bastante) e renderizar os templates usando o `Jinja2`, que é considerado por muitos o melhor sistema de template disponível atualmente no mundo Python. E lá fui eu instalar o Jinja2 e dar uma olhada na documentação. Entretanto, esperando encontrar um jeito extremamente simples e direto ao ponto de salvar meus templates num diretório qualquer e carregá-los via código com uma função ou método simples, me deparo com isso: ![Jinja 2: "the simplest way..."](/files/15) Ah, pronto. Isso aí é o jeito simples? Valeu aê, tô caindo fora **agora**. Me dá a maior preguiça só de pensar que o "loader" fica sempre explícito, assim. Acabei voltando à bela simplicidade da *[Simple Template Engine](https://bottlepy.org/docs/dev/stpl.html)* do próprio Bottle e absolutamente não me arrependi. ### 4- O ORM Trabalhando, atualmente, com um projeto Flask+SQLAlchemy, consigo apreciar ainda mais a beleza do ORM do Django. Inicialmente, na verdade, pretendia usar o [Orator](https://orator-orm.com/), que me parecia bastante similar, mas ainda havia uma coisa ou outra na qual, para o meu gosto, o ORM do Django era superior. Mas o ORM do Django é bastante acoplado ao próprio Django. Então pensei em transformar meu servidor `lazywf` num *management command* do Django. Comecei a escrever uns modelos, novamente, até constatar que, no fim das contas, minha empreitada ainda era tão exploratória que gastar tempo escrevendo modelos parecia meio absurdo. E me dava preguiça. Agora, é importante salientar: eu absolutamente sei quão fundamental é a etapa de planejamento em um projeto. "Projetar" e "planejar", no fim das contas, são espécies de sinônimos. Mas para um projeto do tipo "*só quero que funcione logo + só quero ver no que vai dar*", não planejar nada, sob o risco de jogar tudo fora, eventualmente, me pareceu uma aposta mais interessante. Resultado: decidi absolutamente não escrever modelo algum e depender somente do projeto [dataset](https://dataset.readthedocs.io/en/latest/) que já é incluído no `lazywf` (e cujo slogan é, vejam só, "*databases for lazy people*"). ### 5- Organização do código Certas coisas requerem tão pouco esforço e geram resultados tão satisfatórios que A Mais Profunda Preguiça acaba servindo de incentivo para a adoção de boas práticas. Nesse projeto Flask que mencionei eu ainda tenho grande dificuldade, na maior parte do tempo, de entender meramente "*o que é que está acontecendo aqui?*". O projeto "terceiriza" tanto os comportamentos que entender o que um endpoint faz, por exemplo, acaba sendo questão de ler a lista de *decorators* do método em questão ao invés de olhar o corpo do mesmo. E mesmo que seja um caso exemplar de DRY (*don't repeat yourself*), também acaba deixando o conhecimento sobre a situação "*scattered all around the code*". O que fiz, para evitar ter muito trabalho, foi criar uma grande classe que representa o servidor (poderia até ser tudo com funções, mas certas coisas ficam mais fáceis de se buscar como atributo de `self`) dividida em vários "mixins", cada um representando uma área do sistema: items, collections, login, register, et cetera. E na implementação dos métodos, as regras são (1) não tentar ser espertinho quando não precisa, (2) não ter medo de misturar alguns escopos (por exemplo: carregar a lista de "likes" dentro do código de exibição de um Item) e (3) dar preferência à "queda por gravidade", tornando a leitura do código o mais clara possível: basta começar na linha 1 e prosseguir até o último `return`. ### 6- Object Storage A **Linode** botou no ar sua versão de *Object Storage S3-compatible* por um preço **muito** bom e tão logo precisei subir arquivos (para permitir artigos com **capas** e a inclusão de imagens no corpo dos mesmos) pensei em usá-lo. Mas... subir via HTTP e salvar no sistema de arquivos é **tão** mais fácil. Com um Object Storage o upload seria feito via Javascript, eu teria que gerar uma chave de autenticação temporária e depois do upload eu teria que salvar os dados do arquivo no backend. E fazendo do jeito antigo eu faço tudo isso numa tacada só e com pouquíssimas linhas de código (eu fiz a coisa toda, incluindo checagem de "quota" e exclusão de "entradas defeituosas", em meras 46 linhas). E assim ficou. O armazenamento em bloco do Linode custa cerca de 5 vezes mais que o Object Storage, mas como é muito mais simples e, de qualquer forma, ambos são baratos ao ponto de eu ter que me esforçar para conseguir fazer disso um prejuízo, estou bastante satisfeito com essa decisão. ### 7- Sistema de pagamentos Ainda não decidi como vou implementar os pagamentos, mas como não tenho planos, por ora, de "profissionalizar" a plataforma, provavelmente farei as vendas "na unha" por algum tempo. ## Objetivos Meus objetivos com a plataforma, por enquanto, são **formar uma pequena comunidade** e torná-la cada vez melhor para que, daqui a algum tempo eu possa começar a pensar em novos planos. Acho bem interessante manter uma ferramenta desse tipo. Não é algo que vá pagar meu salário, mas pelo menos existe a possibilidade de não me dar prejuízo, ao mesmo tempo que vou ganhando experiência em tocar um projeto assim por conta própria. Atualmente, inclusive, tenho mais não-objetivos do que objetivos em si. As coisas que **não quero** fazer são: * Incluir anúncios. * Vender os dados dos autores. * Vender a plataforma para alguma empresa. * Conseguir algum investidor que me obrigue a ser "politicamente correto" ou aderir a algum movimento que vá contra as minhas convicções. ### Regras Não pretendo incluir nenhum tipo de "código de conduta". Só não permitirei, obviamente, **conteúdos ilegais ou imorais**. Não é ilegal, por exemplo, defender com pompa e linguajar sofisticado a demolição do conceito de família e a adoção de práticas de pederastia, mas é absolutamente imoral e não quero que uma plataforma mantida por mim e que leva o meu nome sirva de veículo para esse tipo de lixo. ## Experiências anteriores Eu cheguei a lançar um projeto chamado "Deretium", que tinha uma pegada diferente do MyNotes.space. Lá eu pretendia manter uma "comunidade de escritores de artigos" com uma espécie de curadoria de conteúdo. Mas depois vi que não daria muito certo. Prefiro deixar, agora, que quem quiser escrever algo faça-o como preferir. Essa plataforma é menos uma "vitrine" para determinado tipo de conteúdo e mais uma **ferramenta para os autores**. Por isso mesmo o modelo de cobrança ser simplesmente uma anuidade. Não quero ficar tentando prender os leitores a esse domínio ou ficar tentando forçar, de alguma forma, que o tráfego passe por aqui, onde eu teria o controle. Se o autor quiser criar um site à parte e só puxar os conteúdos daqui, que o faça (darei suporte ao acesso via API em breve). Se quiser apenas escrever aqui e publicar em outro lugar, okay também. Futuramente eu até tenho planos de permitir o uso do sistema como backend para outras coisas, como lista de afazeres ou coisas assim. Contanto que não se abuse da plataforma, no sentido de exagerar no uso dos recursos, não vejo problema algum. ## Resumo Está aí lançada a plataforma. Se ninguém quiser pagar para usar, tudo bem: ela serve muito bem para mim. Se quiserem, ótimo: a ideia é que seja **um lugar em que os autores são respeitados**, ao contrário de tantas outras plataformas por há aí. Não pretendo ficar rico com o projeto. Se conseguir uma pequena comunidade de pessas satisfeitas, também satisfeito ficarei eu.

Curti

65 visitantes curtiram esse Item.

Próximo: Robô velho