Lugares onde adiciono coisas 😆
O caminho até aqui...
"Entrei no curso técnico sem saber o que me esperava. Nunca havia
estudado o assunto antes, nem mesmo um computador sabia formatar e nem tinha
noção do quer era programação. Quando era criança queria ser advogado.
A primeiras linguagens de programação que tive contato foram Pascal e Visual
Basic. Quando escrevi meus primeiros programas achei sensacional, realmente
gostei demais e comecei a estudar por conta.
Aprendi C e um pouco de
C++. Também comecei a estudar Python nessa época."
'Durante as primeiras aulas do curso, um dos professores falou sobre o Gnu/Linux. Eu tive pouco contato com computadores durante a infância. Tive acesso a internet um pouco tarde e nunca imaginei que existia algo além do Windows. Do mesmo jeito que me interessei por programação me interessei pelo Gnu/Linux. Comprei uma caixinha do Conectiva 7.'
Com o apoio do meu professor do técnico, Luiz Cavamura Jr, entrei como auxiliar do CPD.
Eram outros tempos. Nesse tempo o estagiário não era tratado como hoje.
Além de ter a mesma carga horária, a gente ainda fazia hora extra. A única
diferença entre o estagiário e o efetivo era o quanto a gente recebia.
Basicamente meu trabalho consistia em formatar computadores, atualizar sistemas
utilizados na empresa e arrancar folhas de papel enroscado de impressoras.
Lá eu aprendi muita coisa, como:
Pedi demissão depois que resolvi me dedicar aos estudos para o vestibular.
"O curso serviu mais para eu conhecer um novo mundo do que me capacitar de fato. Quando sai de lá estava usando Slackware em meu computador, aprendi a compilar customizar o Kernel Linux e havia já instalado e utilizado o FreeBSD como Desktop. Já implementava algumas coisa usando Qt e C++, fiz algumas coisas que nunca foram ao ar com PHP. Gostava muito de trabalhar com infraestrutura e redes."
Entrei no curso de Ciências da Computação em março de 2007. Naquele tempo já sabia bastante coisa, isso foi bom e ruim. Bom porque consegui aproveitar bastante coisas que a universidade oferecia fora das salas de aula e ruim porque não ficava muito tempo nas salas de aulas. Isso me manteve na universidade mais tempo do que eu deveria. No final do primeiro ano já fazia parte do GIA (Grupo de Inteligencia Artificial), mas também já havia adquiridos algumas reprovações em disciplinas mais voltadas a matemática. Tentava adicionar computação em tudo para ficar mais fácil para mim conseguir frequentá-las.
Alguns projetos especiais desse período
Tela inicial do Gueda, aplicação que fiz para o curso de Cálculo I usando C e Gtk+.
Tela mostrando uma pequena integração com o Gnuplot.
Palestras
"Panfleto da Seccomp 2008. Destaquei dois pontos: Os dias em que eu realizei um minicurso de como utilizar o GTK com Ruby e também destaquei algo que para mim foi algo muito especial - no mesmo evento em que falava de Ruby o famoso Fábio Akita também estava falando de Ruby on Rails."
"Durante meus primeiros anos da Universidade descobri que gostava de fazer algo que nunca havia pensado por causa de ser sempre muito introvertido, palestrar. Na época Ruby tinha uma certa novidade e relevância e era uma linguagem que eu estava estudando e ela serviu como tema das minhas primeiras palestra. Falei bastante de Ruby e GNU/Linux na época. Realizei algumas palestras na ETEC em que fiz meu curso técnico, na UNESP e na Asser, uma faculdade de Rio Claro."
Meu foco durante o período
Me envolvi em diversas iniciativas durante meu curso. Participava
poucos das aulas e muito de outras iniciativas. Trabalhei no departamento
de Geologia, no LISG (Laboratório de Interpretação de Dados Sísmicos e Geológicos),
la fiquei responsável por uma pequena rede de computadores SUN Sparc que
rodavam Solaris e um servidor que rodava IBM Aix.
Cheguei a dar manutenção,
durante um curto período de tempo, em um cluster Beowulf (que na época rodava
Fedora Core 2) que ficava em um laboratório do Instituto de Biologia chamado
CEIS (Centro de Estudos de Insetos Sociais).
Também gastei bastante
energia participando na organização da Seccomp 2007 (ajude na criação do
site, configurei um servidor Postfix para enviar os e-mails do nosso site,
fiz o sistema de sorteio do último dia e trabalhei recrutando palestrantes)
e na organização de uma Linux Install Fest (em uma época que instalar o
Linux não era tão simples e baixar uma ISO na internet poderia levar semanas,
quando tínhamos internet).
Foto com Rafael Peregrino. Na época ele era editor da revista Linux Magazine. Segurava meu primeiro notebook rodando Slackware.
Enquanto estava na universidade conheci minha queria esposa,
então precisava de dinheiro. Então comecei a procurar alguns freelas. Nessa
época desenvolvi dois projetos que se destacaram, com um eu não ganhei nada
além de experiencia. O segundo troquei por um notebook e uma pequena quantia
em dinheiro.
Foi nessa época que pensei em abrir uma empresa junto com
um colega da faculdade. Cheguei a fazer um site e um sistema para cadastro
de cliente com uma área onde o mesmo poderia consultar o trabalho executado.
Nessa época só consegui pegar um trampos de configuração de computadores pela
"empresa".
Carla, minha esposa. Foto tirada em 2009 com um celular da época. A Carla, minha melhor amiga e companheira ao longo de todos esses anos, sempre foi fundamental no desenvolvimento da minha carreira. Sempre apoiando e comprando as brigas, sem dúvidas não teria conseguido fazer tudo o que fiz sem ela. Programei muito nesse local onde a foto foi tirada.
Grupo Ação Jovem
Era uma pequena rede social para o grupo de jovens que frequentava
naquela época(o Orkut estava no auge aqui no Brasil). Era mais do mesmo,
subir foto, comentar a foto do coleguinha, enviar recado. Foi utilizado
durante um tempo, até que um dos lideres da instituição começou a colocar
comentário não muito felizes nas fotos dos outros.
Foi nesse projeto
que aprendi a registrar um site e pensar no caminho até produção. O deploy
era simples, basicamente um git pull em um servidor. Nada automatizado.
Alugava um servidor na Locaweb onde configurei Apache, MySQL e a aplicação
em django. Tenho o código o banco de dados guardado até hoje.
TerceiraJC
Um site de divulgação da igreja. Entre os recursos disponíveis estavam uma Bíblia e um sistema de buscas em seu conteúdo, uma listagem com os pregadores do ministério e algumas mensagens que poderiam ser ouvidas em um player no site. Além disso havia o clássico álbum de fotos com direito a comentários. O site nunca foi utilizado como deveria.
No momento em que escrevo esse texto é possível visualizar o site no WebArchive. Não vou deixar um print aqui porque era muito feito. Design nunca foi meu forte.
No inicio de 2010, um colega da faculdade, como sabia que gostava de Ruby, me indicou para uma vaga na CI&T e entrei na empresa. Entrei para trabalhar nos projetos da Editora Abril.
Portal Exame.com
O maior projeto que atuei nessa época foi o Portal Exame.com. Construímos
todo o sistema do zero, desde as páginas principais até todo o CMS por trás
do site.
Utilizamos Ruby on Rails como principal framework. Também utilizamos
algumas tecnologias que eram bem recentes para época, como o Redis, utilizado
para facilitar a criação de alguns indicadores do site, exemplo: notícias
mais lidas por canal e por intervalo de tempos (24 horas, 7 dias e ultimo
mês. No CMS utilizamos conceitos bacanas como edit-in-place para edição
de landing pages e criamos mecanismos totalmente customizáveis para integração
com agencias de noticias parceiras.
Para monitoria do site utilizávamos
o NewRelic como APM, tecnologia também bem recente para a época.
Do
ponto de vista de metodologia de desenvolvimento, além de adotarmos o ágil
para valer, discutíamos e utilizávamos com bastante frequência o TDD e já
discutíamos como utilizar BDD no nosso projeto.
Tenho muito orgulho
desse projeto porque além das grandes conquistas tecnológicas obtivemos
grande sucesso do ponto de vista de negócio. Os usuários, em sua grande
parte jornalistas da editoria, receberam o novo sistema muito bem e após
entrevistas vimos os ganhos no dia a dia dos usuários.
Esse projeto
foi um celeiro de aprendizados: CI/CD automatizados, SCM permitindo hotfix
sem dores, visibilidade do que está acontecendo em produção e estratégias
de cache. Nem parece que foi um projeto executado a mais de uma década comparado
a maturidade de outros projeto que passei depois desse.
Criação do meu Blog
Durante essa época, tentei mais uma vez, criar um site para mim
para disponibilizar alguns textos sobre desenvolvimento e até que vingou.
Fui bem ativo nos anos de 2011 e 2012. Cheguei a receber muitos comentários,
a maioria pedindo ajuda.
A primeira versão foi em wordpress mesmo,
com um tema pronto e hospedado no wordpress.com. Em pouco tempo migrei o
site para uma instancia rodando em um servidor em uma conta que tinha na
Linode. Depois evolui muito o sistema do meu site, mas falarei mais para
frente aqui na timeline.
Cheguei alguns textos que tiveram muitos acessos
e tem até hoje. Exemplos são:
Primeira carinha do meu site
FrontFile
Em uma época que estava gastando muito tempo com Ruby, senti a necessidade de estudar alguma coisa diferente. Comecei a estudar Perl com mais afinco e dentre os projetos desenvolvidos na linguagem o único útil foi o FrontFile, que nada mais é do que dois scripts que realizam buscas em arquivos. Utilizei durante muitos anos até começar a utilizar o ripgrep.
Também desenvolvi uma interface gráfica para os comandos em C e GTK. Este projeto encontra-se dentro do mesmo repositório no GitHub, porém nunca foi utilizado, acredito eu. Por ser antigo - o último commit foi realizado em 2011 - a interface gráfica não é tão simples de ser compilada mais, pois foi desenvolvida em GTK2 e hoje, a maioria das distribuições GNU/Linux utilizam a versão 3 como padrão.
A instalação também torna disponível duas páginas do manual que exibe os recursos dos comandos. É possível acessar a documentação através do comando man.
Minha saída da Ci&t
Nessa época eu ainda não havia terminado a faculdade. E ir todos os dias para Campinas (passava umas 4 horas do meu dia com translado) não estava ajudando muito com minhas pendencias acadêmicas. Como achava fundamental fechar esse ciclo acadêmico, resolvi a sair da Ci&t e trabalhar na cidade onde estudava. Sai com um ano e cinco meses de casa. Foi quando começou período da minha vida que costumei chamar de "pior fase da minha vida profissional".
Na época eu não tinha noção de quanto a minha ida para trabalhar nessa empresa me faria mal. Sem brincadeira, tenho pesadelo até hoje com esse lugar. Não vou me aprofundar muito, foi resumir da seguinte forma: fiquei durante dois anos como estagiário, virando noites trabalhando e nunca ganhei um real de hora extra. Achei que estava ajudando a construir algo, no final construí algo sim, mas para outros. "Inocência", alguns podem usar essa palavra para isso, eu chamo hoje de "burrice".
O que eu fiz para meus empregadores
Quando iniciei meu trabalho na empresa os projetos basicamente eram desenvolvidos em JavaScript, Java e XUL. Eram aplicações desktop. Não haviam testes automatizados e muito pouco rodavam na web. Não havia metodologia de desenvolvimento, falavam que utilizam a metodologia Free As A Bird. Ainda usavam SVN para todos os projetos. Com o tempo comecei a apresentar algumas coisas, como o git, ruby, tdd, scrum. Quando sai de lá o projetos que mais estavam rendendo utilizavam Ruby on Rails e eram aplicações web. Havia uma preocupação com testes unitários e uma organização melhor. Sinto que fiz a diferença naquele lugar, porém perdi muita coisa naquele lugar, financeiramente e emocionalmente. Bom, e parafraseando a personagem Forest Gump, isso é tudo que quero falar sobre isso.
O que fiz fora dos escritórios de meus empregadores
Da mesma forma como acontece quando estudamos o período Idade Média no ensino fundamental, quando ouvimos falar que não foi produzido muito conhecimento durante essa época, porém quando aprofundamos notamos que não é uma verdade, fora do escritório de meus empregadores produzi alguns projetos que me orgulham muito e alguns utilizei por muito tempo e um deles utilizo até hoje. Vou descrever aqui os principais.
Apontamento
O projeto ainda não está disponível em nenhum repositório publico. O motivo disso é que ele foi desenvolvido na correria entre os projetos do meu emprego e as disciplinas da UNESP e com isso o sistema foi criado com diversos bugs e gambiarras.
O objetivo do projeto é um controle de horas gastas com os projetos que trabalho. Ele foi fundamental durante o tempo que fiquei nessa empresa porque lá não havia nenhum controle de horas, depois de alguns anos um foi criado, mas quando construí o meu não havia nenhum. Utilizei o meu sistema de apontamento durante alguns anos, inclusive até durante a Ci&t para controlar meus tempos. Sempre gostei de fazer esse tipo de gestão das minhas tarefas. Até sei o que fiz em outubro de 2012. Hoje ele foi arquivado pois construído um mais adequado, co o tempo ele ficou muito obsoleto.
O dashboard tinha como objetivo mostrar o que era esperado e o executado para o dia e os períodos trabalhados durante o dia. E suportava múltiplos projetos.
Além de apontamento de horas, também foi construído um Kanban para gerenciar histórias e tarefas.
O sistema foi criado utilizando Ruby on Rails.
Gnomato
Além de desenvolvimento e de servidores e sistema operacionais, uma outra área que gosto muito de estudar é coisas relacionadas a metodologias. Por gostar bastante e sempre tentar aplicar o metodologia Pomodoro no meu dia a dia eu implementei o Gnomato. O Gnomato é um aplicativo criado para servir como um timer para a técnica de gestão de tempo chamado Pomodoro. Foi construído visando o ambiente GNU/Linux, por isso foi escrito utilizando como base a biblioteca gráfica GTK.
A aplicação possui um sistema de plugin desenvolvido em Python, o que facilita a integração com outros sistemas. O sistema Apontamento, mencionado acima, recebia as entradas através de um plugin do Gnomato. Exemplo dos hooks disponiveis estão em aqui.
Na imagem mostro a integração do status do Gnomato com a barra do ambiente cinamon. A comunicação se da através de uma api D-Bus.
Outro recurso interessante na construção foi o uso do mecanismo D-Bus, que torna fácil a recuperação dos estados do Gnomato e que facilita a integração com outras aplicações.
Utilizo essa aplicação até hoje, ele ainda serve como fonte dos meus apontamentos de hora. Eu escrevi um artigo sobre o meu fluxo de trabalho atual onde o Gnomato é utilizado e pode ser encontrado aqui.
O repositório do Gnomato fica em https://github.com/diegorubin/gnomato.
RunMySource
Sempre gostei muito do Spoj e sempre pensei em construir algo para utilizar em minicursos de programação. Em uma das disciplinas da UNESP, tivemos que desenvolver um projeto com tema livre, a única obrigatoriedade era o uso da linguagem de programação que havíamos escolhido estudar no começo do semestre, que no meu caso era Erlang. Já havia algum tempo que tinha interesse em estudar essa linguagem. Então resolvi junta o útil e o agradável.
A ideia do RunMySource é primeiramente escrever o código no site e executá-lo lá mesmo. Atualmente as linguagens suportadas são: C, C++, Clipper, C#, Erlang, Fortran, Java, Lua, Objective-C, Pascal, Perl, PHP, Prolog, Python, Ruby e Rust.
No screenshot é exibido a execução de um código escrito em Fortran.
Além disso, foi construído de avaliação nos formatos do Spoj, onde é possível criar problemas e criar avaliações para que alunos submetam seus códigos escritos como solução dos problemas.
O sistema foi validado em dois momentos: A primeira foi durante o minicurso sobre Ruby que ministrei durante a SECCOMP 2012. Durante o evento foram dados alguns problemas simples e foi pedido para que alunos do minicurso enviassem as soluções. Os registros ainda estão no site no seguinte endereço: http://runmysource.com/courses/3. Também escrevi um pequeno texto na ocasião: Run My Source e a SECCOMP 2012.
A segunda validação que obtive foi durante a disciplina Simulação Estocástica. Na disciplina deveríamos utilizar Fortran para resolver os exercícios. Eramos obrigados a utilizar uma versão no compilador para Windows. Ao invés de utilizar esse sistema, utilizei o RunMySource para resolver todos os exercícios e assim não precisei utilizar o Windows e não tive nenhum problema. Ainda tenho todos os exercícios resolvidos na minha conta do sistema.
O core do sistema foi construído em Erlang. Foi implementado um serviço que é responsável pela execução do código. Existe uma pequena parte que utilizei Python para comunicação do Erlang com o Sistema Operacional. O site, o sistema que se comunica com o core em Erlang, foi desenvolvido em Ruby on Rails.
Na época utilizei o chroot para criação de sandboxes para execução dos código, cheguei a escrever um artigo sobre isso, Criando uma Jail utilizando Chroot no Fedora ou CentOS, atualmente a aplicação é executada em um cluster k8s.
Desenvolvimento Android
Neste ano comecei a estudar Android depois de ganhar meu primeiro aparelho com o sistema. Meu primeiro teste com desenvolvimento para Android foi a criação de uma gambiarra para que meu celular funcionasse como controle remoto para apresentações com slides.
Nessa primeira tentativa não utilizei a API em Java, mas usei outro projeto que possibilitava o uso de Ruby para criação de aplicativos Android. Foi a primeira e última vez que criei um aplicativo para Android dessa forma, pois o resultado final é lento e grande demais.
Funcionava da seguinte forma: o aplicativo envia uma mensagem a um servidor http com um possível comando, então esse comando era repassado para um cliente que enfim enviava o código para o X11.
O mais legal do projeto foi ter desenvolvido uma classe utilizando a API do Ruby em C, pois o Ruby não tem acesso ao X11 diretamente, ou pelo menos não tinha encontrado uma classe que já implementava isso. O código em questão está presente nos arquivos x11_display.h e x11_display.c.
Depois dessa experiencia comecei a estudar a API do Android em Java para desenvolver aplicativos nativos. Cheguei a escrever uma série de artigos sobre o assunto que chamei de CarnAndroid, pois foram escritos durante o Carnaval de 2012 - criativo, não é mesmo? Os artigos são os mais acessados do meu blog até hoje e podem ser encontrados neste link.
Vortex - Meu Trabalho de Conclusão de Curso
Como meu TCC, desenvolvi um indexador de páginas web em Erlang - nada de novo, realmente nada de novo. A ideia era aplicar algumas metodologias de processamento de linguagem natural que havia estudado anteriormente. Desenvolvi o sistema pensando em escalabilidade e uma boa forma de indexação.
Outra tecnologia que utilizei no projeto que achei fantástica e que ainda preciso dar continuidade nos estudos é o banco de dados NoSQL chamado Riak.
Nunca mais evolui ou utilizei o projeto, mas ainda o consulto quando vou desenvolver algo em Erlang. O repositório do projeto pode ser encontrado no GitHub.
Indepedent CMS
Em 2011, depois de abandonar o Wordpress como CMS - a ideia sempre foi utilizá-lo temporariamente - construi meu próprio CMS, utilizando Ruby on Rails e MongoDB. Ele foi desenvolvido de uma forma não muito reaproveitável, tinha muita coisa não parametrizada e por isso não publiquei o código em nenhum repositório público na época.
Esse foi a primeira cara do meu site depois que deixei de usar o Wordpress.
Em 2014 resolvi começar o projeto do zero, utilizando as mesmas tecnologias, porém de uma forma totalmente parametrizável para que pudesse ser reutilizado de forma simples. Eu cheguei a utilizar o CMS em alguns outros sites que disponibilizei.
Esse é um print do meu site depois da versão opensource do meu CMS e o primeiro template implementado no novo sistema.
Criei um pequeno e simples sistema de templates, com isso posso distribuir o código do CMS sem que tenha que disponibilizar também o layout do site. Também criei um pequeno sistema de widgets que ainda precisa ser melhorado muito, mas que já está me uso.
Esse é o print de um site que fiz para publicar alguns textos de teologia e filosofia. Utilizava o mesmo CMS, só implementei um novo template.
O código poder ser encontrado em https://github.com/diegorubin/independent.
Minha saída da empresa
Depois de me dedicar realmente a melhorar a empresa e receber muito pouco em troca (basicamente meu salario, e como disse, nem 1 real hora extra recebi) resolvi aceitar o convite de um conhecido da Unesp e mandei um cv para a empresa onde trabalhava, chamada Kaffa Mobile. Fui aprovado no processo da Kaffa Mobile e fui para lá.
O trabalho na Kaffa Mobile era bem legal. Realmente haviam problemas de algoritmos legais de serem resolvidos. Não vou entrar em detalhes, até por que não seria bacana, mas posso dizer que basicamente trabalha com Java, SWT e um pouco de Lua. Trabalhei na aplicação Desktop que também era executado em Tablets com Windows.
Minha saída da empresa
Fiquei cerca de 80 dias na empresa. O principal motivo para ter ficado pouco tempo é que diferente das minhas oportunidades anteriores, na Kaffa senti que havia muita pouca liberdade. Tenho um exemplo demostrar meu ponto: Estava acostumado a trabalhar utilizando dois monitores, na empresa havia um notebook para trabalhar (que não poderia levar para casa e não poderia instalar a distro que gostasse) e eu pedi se eu poderia levar um monitor meu, que estava sem uso em casa para utilizar no escritório, negaram meu pedido. Até entendo uma empresa grande não permitir esse tipo de coisa, mas era basicamente uma sala. Esse um exemplo, não vou entrar em outro detalhes.
Um dia, um conhecido que trabalhava na Ci&t me mandou mensagem dizendo que havia uma vaga para trabalhar com Ruby. Resumindo a história, sai de casa cedo para ir trabalhar, na hora do almoço conversei com uma pessoa da Ci&t, a tarde estava pedindo demissão da Kaffa, isso em uma terça-feira. Na sexta-feira foi meu ultimo dia na Kaffa, na segunda-feira estava sendo recebido na Ci&t para minha segunda temporada.
Voltei para a Ci&t como Developer Pleno. Já era uma Ci&t bem diferente da que eu havia conhecido em 2010. Cheguei na semana do natal e fiquei muito pouco tempo em um time que já estava rodando. E realmente estava feliz, mesmo hoje, depois de quase uma década, ainda lembro com alegria daquele momento.
No inicio de janeiro fui para o time onde iria trabalhar realmente.
Vou descrever alguns projetos que trabalhei, porém não poderei entrar em muitos detalhes. Entrarei em mais detalhes nos projetos OpenSource e outras ferramentas que desenvolvi durante esse período.
Rastreio de Pedidos
Entramos no projeto para trabalhar em no módulo, deste que na epóca era um grande player, de rastreio dos pedidos. O módulo era desenvolvido em Ruby, havendo um portal administrativo e algumas APIs usando Ruby on Rails, e outros módulos em formatos de jobs, que utilizavam filas e RabbitMQ.
Aplicativo Android
Durante o projeto nosso PO teve a iniciativa de desenvolver um aplicativo para ser utilizado pelos entregadores para que fosse possível ter uma visão mais realista do tempo de entrega dos pedidos.
Essa foi uma etapa bem interessante do projeto. Em cerca de um mês desenvolvemos um aplicativo Android nativo (Java), implementamos algumas APIs publicas para ser utilizada no aplicativo, um sistema de sincronia dos dados e um sistema de sessão para que o aplicativo continuasse funcionando offline.
Pensando na minha carreira, essa foi uma oportunidade interessante onde pude explorar outros aspectos. Pegar o carro e ir para São Paulo, no cliente, sozinho, para discutir e aprovar soluções com times responsáveis por segurança, release, GMUD, etc... Foi uma época que consegui ampliar bem minhas capacidades de comunicação.
Análise de Fraude
Depois do projeto de rastreio dos pedidos, trabalhei por algum tempo no módulo de Análise de Fraudes.
Não existiu uma grande dificuldade ou novidade nesse módulo, basicamente era alguns processos que chamavam APIs de terceiros (de serviços especializados de analise). Esses processos foram construídos utilizando Java e Springboot. Mas foi útil para mim, foi uma oportunidade de me atualizar em algumas coisas relacionadas ao Java depois de anos trabalhando com outras linguagens.
Nessa época desenvolvi e publiquei em um repositório oficial meu primeiro projeto opensource, chamado SEMS.
Simple Environment Monitor System
O ambiente de desenvolvimento do projeto era bem complexo e instável e era comum ter que validar varias coisas de forma manual antes de iniciar algum teste de ponta a ponta.
Dado esse cenário pensei em criar rotinas para validar se as integrações estavam funcionais. Esse projeto acabou evoluindo e tornou-se um painel configurável e que funcionava com base em plugins. O projeto está publicado no PyPI em https://pypi.org/project/sems/.
Exemplo de painel do SEMS mostrando serviços funcionais ou não.
Parei de evoluir o projeto quando iniciei o Lifeguard, que descreverei um pouco mais para frente.
Construção de uma plataforma do zero
Meu segundo projeto na Torre de E-commerce é algo que me da muito orgulho de ter participado. O objetivo era construir uma plataforma multi tentant do zero para um grande player brasileiro.
Eu trabalhei, na maior parte do tempo, em dois módulos. O módulo de campanha e o front.
Módulo de Campanhas
O objetivo do módulo era fornecer APIs que seriam utilizados por outros módulos, como os das páginas de produtos e o checkout, para realizar cálculos de descontos. Foi desenvolvido utilizando Java 8 e SpringBoot e utilizando o MongoDB para persistência dos dados.
Foi um projeto bem divertido de ser desenvolvido. Havíamos adotado uma cobertura de código muito alta, buscando o 100% de testes unitários e integrados de forma automatizada. E além disso, testes de componente escritos utilizando Gherkin, foram uma forma bem legal de garantir nossa qualidade após diversos refactor que foram feitos visando performance. A qualidade do módulo foi realmente um ponto de destaque do projeto.
Durante a construção desse módulo nasceu o SEL, que foi utilizado como uma engine para descrever e aplicar as promoções.
SEL - Simple Embedded Language
Durante o projeto, fui notando que muitas das demandas eram implementações de possíveis promoções e formas de descontos. Em paralelo comecei a trabalhar em uma forma de descrever essas regras sem estar atrelada ao código compilado do Java. Desenvolvi o SEL em paralelo ao projeto (durante finais de semana e nas minhas idas e voltas do trabalho no fretado) uma pequena linguagem para ser interpretada em runtime no projeto desenvolvido em Java. A ideia era permitir que o time de negócio conseguisse editar essas regras sem um deploy ou reload da aplicação.
Depois de conseguir replicar todas as lógicas construídas utilizando o SEL (aqui os testes de componentes ajudaram muito). Também fizemos POCs para testar a performance da solução e, por fim, implementamos no código final. A solução acabou indo para produção e o SEL virou opensource.
TShield
Após finalizar o Módulo de Campanhas, passei a trabalhar na equipe que desenvolvia o front-end do novo sistema, onde foi utilizado Dustjs.
Durante o desenvolvimento desse módulo, enfrentei um pequeno obstáculo: os arquitetos do cliente solicitaram que não investíssemos tempo em testes unitários. Para mim, isso representava um risco significativo. Eles argumentavam que toda a lógica de negócios estava na API (o que era verdade) e que, portanto, não era necessário investir em testes no front-end (o que, para mim, não fazia sentido, devido às lógicas de transformação e apresentação dos dados).
Para não entregar um produto sem testes em um curto prazo, pensei em criar testes de componentes, simulando as APIs consumidas pelo front-end. No entanto, criar mocks é algo que demanda tempo e manutenção.
Para facilitar a criação de mocks, desenvolvi uma ferramenta chamada TShield.
O TShield é um servidor de mocks que grava as requisições e respostas de um serviço, podendo ser utilizado posteriormente para simular o serviço real. Com isso, eu poderia gravar as respostas da API e simular o serviço no front-end.
Essas respostas são gravadas em arquivos e versionadas no repositório, permitindo que o front-end seja testado de forma independente da API, sem precisar criar muitos mocks. Se houver alguma alteração na API, basta gravar a nova resposta e atualizá-la no repositório.
Atualmente, o TShield possui diversas outras funcionalidades, como simulação de latência, criação de mocks dinâmicos e manuais, além de suporte a APIs gRPC.
Mais detalhes podem ser encontrados em https://github.com/diegorubin/tshield.
Se você chegou até aqui e quer me enviar uma mensagem, sim você pode. Me mande um e-mail através do endereço contact@diegorubin.dev.
See you space cowboy...
Você precisa estar logado para usar o chat. Faça login utilizando uma conta Google.
Login com Google