fbpx
Oragon.Spring
Publicado em: quarta-feira, 20 de jun de 2018

Se você caiu de paraquedas aqui e não entendeu nada do assunto, calma eu vou explicar. O Spring.NET é um container IoC super robusto, mas não caiu na graça da comunidade. Uns reclamam de lentidão, outros reclamam do xml outros reclamam por ter sido inspirado no Spring do java. Eu gosto e defendo sua abordagem, o Spring.NET é alicerce das minhas arquiteturas no .NET Framework, e já faz muito tempo que sinto falta dele no .NET Standard / .NET Core. No post Spring.NET o Renascimento eu fiz um overview sobre o assunto, mas há muito mais assuntos relacionados quando olhamos para tags como Dependency Injection, DIInversion Of ControlIoC, e claro, não poderia faltar Spring.NET. A questão é: Agora, oficialmente, estou tocando um fork do projeto, quer participar? Fale comigo!

#spring-net/issues/133

A saga com o port do projeto começa bem antes de fazer meu primeiro port do projeto, em Setembro/2017. Eu já estava adiando alguns projetos esperando pela movimentação a respeito da issue issue #133 | .NET Core support, inclusive em no final de setembro de 2017 publiquei uma espécie de incentivo, mostrando que era possível migrar sim e que não seria algo tão complexo. A primeira decisão seria quebrar o projeto, já que migrar o Spring.Core e Spring.AOP representava um esforço muito pequeno, e daria uma boa sobrevida ao projeto. Seria aqueles 20% de esforço que geram 80% do resultado! Na prática, em menos de 12 horas era possível, para qualquer mantenedor assíduo/profundo conhecedor do projeto realizar esse refactoring. O resultado dessa empreitada foi o surgimento de uma frente de trabalho, conduzida por Jeffrey Schultz (Newport News, VA, US) mas que foi paralisado.

#spring-net/issues/144

Na issue #144 | I wish to join this project to help get it going again Jeffrey, eu, mantenedores e outros curiosos abordamos o futuro do projeto. Minha opinião é bem simplista: Migrar mais de 15 módulos é um esforço que não gera tanto resultado. Migrando os principais, seria possível reengajar a comunidade, possibilitando a chegada de sangue novo para a migração dos demais módulos. Spring.Core e Spring.AOP, alicerces do framework, poderiam ser migrados primeiro, em job de míseras 12 horas. Os demais poderiam usar o empenho da comunidade ou simplesmente serem adiados para o futuro. Isso já faria com que o projeto não morresse. O fork do Jeffrey não durou muito e já parou! 🙁

Spring.* ➡ Summer.* ➡ Oragon.Spring.*

Jocosamente batizei o primeiro fork/demo de Summer.* (Summer.Core e Summer.Aop) 😎 como um trocadilho ao Spring. Naquele momento eu queria mostrar que era possível dar um primeiro passo. Eu não estava preocupado com mais nada além de dizer: Hey guys, we can do that!

Mas o tempo foi passando, sem nenhum posicionamento definitivo, nenhuma atitude, vez ou outra aparecendo um pull request do capeta com uma bizarrice qualquer, enfim, nada aconteceu. Agora, no final de junho/2018, cansado dessa inércia, resolvi seguir em frente e tocar meu fork. Agora rebatizado de Oragon.Spring, sobre o org Oragon no github, migrei os fontes do primeiro fork criando uma baseline nova. Nesse momento assumo a briga, abraço a causa e sim temos um projeto surgindo.

Por que só agora?

Não fazia sentido criar um fork sem que houvesse divergência. Manter um projeto desses é extremamente custoso, exige cuidado, atenção, ocupação e preocupação. Pra piorar, nunca tive ambições no refactoring do projeto em si, apenas pequenas melhorias em performance, otimizações, coisas básicas. Nunca vislumbrei um roadmap para o projeto, pois nunca me senti “dono” do projeto. Agora é hora de pensar nessas coisas, e portanto, exige cuidado, carinho e uma dose de esforço, assim como um filho.

Quando um projeto morre ou sai da sua mão, é ótimo, pois o tempo que aquele projeto tomava e passa a não tomar mais, abrindo possibilidades para outros projetos ou para simplesmente não fazer nada. Os argumentos que demandaram a criação desse fork não são tão nobres, mas justificam o esforço, afinal, ao meu ver não há substituto à altura hoje. Eu esperei enquanto dava para esperar, agora, estou sentindo a dor de não ter, ao meu ver, substituto, com tais características me suportando no desenvolvimento, e estou prestes a começar alguns projetos novos dos quais preciso ter uma infraestrutura que me de suporte da forma que eu preciso.

Próximos passos

O projeto está no ar, em breve publicarei as novidades.

Ainda falta:

  • Trazer a documentação
  • Refatorar a documentação com base
  • Fundir Spring.Core e Spring.Aop em um só [projeto|pacote|dll].
  • Rever readme, licença
  • Criar uma infraestrutura de integração contínua
  • Achar uma forma de realizar upgrades automáticos de pacotes nuget (para achar quebras de forma proativa)

Até lá! Nos vemos nos próximos capítulos dessa novela!

O Cloud Native .NET é meu principal projeto.

Onde empenho energia para ajudar, acompanhar, direcionar Desenvolvedores, Líderes Técnicos e jovens Arquitetos na jornada Cloud Native.

Conduzo entregando a maior e mais completa stack de tecnologias do mercado.

Ao trabalhar com desenvolvedores experientes, eu consigo usar seu aprendizado com .NET, banco de dados, e arquitetura para encurtar a jornada.

Ao restringir à desenvolvedores .NET eu consigo usar do contexto de tecnologias e problemas do seu dia-a-dia, coisas que você conhece hoje, como WCF, WebForms, IIS e MVC, por exemplo, para mostrar a comparação entre o que você conhece e o que está sendo apresentado.

É assim que construímos fundamentos sólidos, digerindo a complexidade com didática, tornando o complexo, simples.

É assim que conseguimos tornar uma jornada densa, em um pacote de ~4 meses.

Eu não acredito que um desenvolvedor possa entender uma tecnologia sem compreender seus fundamentos. Ele no máximo consegue ser produtivo, mas isso não faz desse desenvolvedor um bom tomador de decisões técnicas.

É preciso entender os fundamentos para conseguir tomar boas decisões.

0 comentários

Enviar um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

[docker de a a z]

Lives

Fique de olho nas lives

Fique de olho nas lives no meu canal do Youtube, no Canal .NET e nos Grupos do Facebook e Instagram.

Aceleradores

Existem diversas formas de viabilizar o suporte ao teu projeto. Seja com os treinamentos, consultoria, mentorias em grupo.