DEV Community: Alex Rios

Is Golang duck typed?

Alex Rios — Mon, 06 Jul 2020 12:03:48 +0000

Hum... Not really!

It's a common misunderstanding because in fact it can relate to the duck type mantra:

If it looks like a duck and quacks like a duck, it's a duck

We can achieve this effect this way

Ok but what is the difference?

Well, the duck typing is resolved in runtime (ruby, python) while in Go it occurs in compile time.

Because of that, in Go it is called structural typing
(sometimes you'll find it named as signature-based polymorphism).

O que é um Tech Leader em 2020?

Alex Rios — Thu, 05 Mar 2020 15:38:20 +0000

O que tem ocorrido muito no cenário das empresas de tecnologia é querer contratar apenas desenvolvedores sêniors.

Principalmente por estar contratando um conjunto de habilidades e experiências, acredita-se que essas pessoas já serão operacionais desde o dia 1 na empresa, economizando o famoso tempo de Ramp-Up.

Ramp-up — etapa que define o ínicio da produção de uma indústria, com o objetivo de comercializar um produto novo

Com isso, desenvolvedores com pouca ou nenhuma experiência ficam jogados de lado na atual guerra das contratações.
Mas será que precisa mesmo ser assim?

Por que ter um líder técnico?

Quando a empresa contrata bons líderes, permite que seja possível contratar o time baseado em seu potencial, personalidade e atitude.

Entendo que o papel de um líder técnico é continuamente trabalhar no crescimento dos profissionais ao seu redor, sendo exemplo cultural e capacitando a equipe quando necessário.

Times empolgados e bem cuidados cuidarão melhor do seu produto e consequentemente dos seus clientes.

Interagir com as pessoas é o diferencial de uma posição de liderança. Inclusive, acredito ser um ponto de atenção quando o líder passa mais tempo em tarefas individuais do que interagindo com seus colegas de equipe.

Faça a seguinte reflexão: O que é mais fácil, ensinar um desenvolvedor sênior com postura pouco profissional a ser comprometido ou ensinar hard skills para um profissional comprometido pouco experiente?

Um diferencial gigante entre bons líderes e líderes em formação é a capacidade de identificar o momento da sua equipe para decidir a melhor forma de agir, e não apenas ter uma solução única que tenta atender a todos os cenários.

Não é possível cobrar a tão aclamada autogestão em times que estão trabalhando 10 horas por dia e sempre correndo atrás da próxima entrega. Aliás, autogestão não é algo que o líder deva cobrar da equipe a qualquer momento. Sua equipe tem pessoas que sabem se autogerir? Se a resposta é não, você como líder deve ensinar isso no dia-a-dia.

A menos que você seja o Thanos, as coisas não vão mudar em um estalar de dedos.

Não acredite que uma metodologia estabelecida ou um processo de desenvolvimento famoso vai resolver os problemas da sua equipe magicamente. Sim, eu estou falando com você, Scrum.

O que funciona para sua equipe não vai funcionar para as outras e vice-versa. Construa seu próprio framework baseado no que funciona e em revisões constantes do processo.

O ciclo da loucura

Sua equipe passa mais tempo corrigindo problemas do que entregando valor, seja ele em forma de melhorias ou novas features?

Se a resposta é sim, então sua equipe está no ciclo sem fim da loucura.

Uma equipe ultra atarefada não tem tempo de evoluir. Pessoas desenvolvedoras que não têm tempo para estudar ou testar novas técnicas como, por exemplo, TDD (Test Driven Development), não vão parar de gerar dívidas técnicas do dia para a noite.

Seguindo esse raciocínio, se sua equipe não tem tempo de aprender a testar melhor o próprio software, vai estar apagando incêndios na maior parte do tempo.

Se o líder técnico passa esse conhecimento ou consegue tempo para que a equipe aprenda mais a respeito, o efeito colateral será ter menos bugs e consequentemente mais tempo.

Entende que é um ciclo vicioso de cada vez ter mais calma para tomar as decisões no caminho da evolução? Mais tempo para investir, mais frutos para colher.

Seu papel como líder técnico em cenários que beiram o caos é criar tempo para sua equipe evoluir.

Como identificar que o ciclo de loucura acabou?

Basicamente com 2 pontos:

Existe tempo para aprender.
O tempo é usado para aprender.

Quando se tem apenas o item 1, na verdade sua equipe só está entregando menos sem nenhum motivo aparente para tal.

Deve existir uma atenção constante para que aconteça o item 2.

Como se manter nessa fase de forma saúdavel?

Traga desafio para quem desenvolve, para que se mantenham fora da zona de conforto técnica.
Apenas um aprendizado por vez. Não queremos ninguém da equipe em um ciclo de loucura novamente, mas dessa vez de aprendizado. Lembre-se: antes elas não aprendiam nada, agora já aprendem. Vá com calma.
Monitore! Números são importantes. Sem números suas avaliações serão subjetivas. O monitoramento não serve para gerar um ranking entre as pessoas ou estimular competição, mas para incentivar cada pessoa a ser melhor baseada nos números dela mesmo. Não consigo ver nenhuma boa intenção em comparar os números entre as pessoas.

Nota: Não é para criar uma vida infernal para ninguém. Saúde mental é importante, desafie respeitando os limites individuais das pessoas.

Acabou? Ser um líder técnico é só isso?

Na verdade, não. Apenas temos uma forma de trabalhar mais racional e com pessoas melhorando seus skills técnicos. Agora chega o momento onde você como líder técnico realmente mostra um valor inestimável: construir novos líderes.

A intenção é que as pessoas sejam líderes delas mesmas, antes de pensar em liderar outras pessoas.

Equipes auto-gerenciáveis

Ensinar o time a resolver o seus próprios problemas.
Ensinar o time a lidar com situações inesperadas.

Sabe o que vai acontecer quando o time for capaz de fazer essas 2 coisas? Você vai ter a tão sonhada auto-gestão.

Entende como até chegar aqui temos um processo não trivial de construção da equipe?

Nesse momento o trabalho do líder não envolve coaching técnico ou profissional, mas a manutenção do time no atual estágio de maturidade.

Com isso já vai ser possível:

Ter metas em vez de tarefas.
Observar e monitorar o time para possíveis oscilações, para não termos uma regressão no modo da equipe trabalhar.

Bônus

OKR

Não é sem motivos que os OKRs (Objective & Key Results) não dão certo em todas as empresas. Equipes que não estão próximas da auto-gestão precisam ser informadas sobre o que fazer baseadas nas metas estabelecidas, pois justamente não desenvolveram a capacidade de escolher com qualidade por si próprias as ações para atingir as metas.

Vou me fazer repetitivo aqui, mas não vai ser contratando mais sêniors que esse problema vai ser resolvido.

Conclusão

O líder técnico tem um papel chave para criação de equipes de alta performance e autogerenciáveis. Se o líder técnico não está formando profissionais melhores, talvez essa pessoa seja apenas uma referência técnica ou especialista em algum tema de tecnologia — e não um líder.

Um bom líder forma outros líderes e guia o caminho para a tão falada equipe autogerenciada.

How to use your private Go lib in Github Actions

Alex Rios — Thu, 30 Jan 2020 14:43:02 +0000

In this tutorial I'll use the fictional private repository called github.com/alexrios/superlib at the version v1.1.0

Backing story

During the Continuous integration pipeline executing go mod tidy I was getting this error:

go: github.com/alexrios/superlib@v1.1.0: reading github.com/alexrios/superlib/go.mod at revision v1.1.0: unknown revision v1.1.0

Why?

In order to understand how Go uses a VCS to handle dependencies I recommend this Go team blog post: https://blog.golang.org/publishing-go-modules

Solution

Generate a token with read permission on org or user repositories and setup a substitution in git global configurations.

That way the authenticated form will always be used.

I highly recommend you to use the repository secrets to avoid exposing sensible data, in this case, the token.

- name: Granting private modules access
        run: |
          git config --global url."https://${{ secrets.GO_MODULES_TOKEN }}:x-oauth-basic@github.com/alexrios".insteadOf "https://github.com/alexrios"

more on declaring and using secrets: https://help.github.com/pt/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets

Using private Golang libs

Alex Rios — Sat, 21 Dec 2019 03:51:38 +0000

1 - Configure GIT (~/.gitconfig)

[url "ssh://git@github.com/"]
    insteadOf = https://github.com/

2 - Add the private repository location in GOPRIVATE env var

go env -w GOPRIVATE="github.com/<org>/<project>"

2.1 - You can add a whole organization accepting all projects with *

go env -w GOPRIVATE="github.com/<org>/*"

Tem certeza de que seu time pode usar micro serviços?

Alex Rios — Sat, 14 Dec 2019 04:21:54 +0000

A maioria das empresas está mirando chegar no topo do nirvana arquitetural utilizando-se de tecnologias de ponta. Infelizmente, o que observo são movimentos desesperados de executar o que se lê em artigos de fonte, no mínimo, duvidosa. Isso quando a intenção não é simplesmente um desejo irresponsável de um grupo de desenvolvedores de mostrar (no LinkedIn? para amigos? para uma talk na conferência da esquina?) que consegue.

Vamos imaginar que você tenha autonomia para adotar uma arquitetura de micro serviços em sua empresa. Antes de quebrar seu monolito em várias partes, na esperança de que magicamente isso transforme seu sistema atual em uma arquitetura de micro serviços, existe um conjunto de questionamentos que devem ser feitos.

Tem apoio organizacional?

Após várias pesquisas você viu os benefícios que a Netflix, Spotify, entre outras empresas tiveram ao adotar o modelo arquitetural e agora tem certeza de que se funciona com eles, então obviamente funciona para você, certo?

ERRADO!

Cada caso é um caso.

Como sua empresa lida com uma falha ou um bug? Ela procura por culpados quando algo da errado em produção ou tenta aprender com as falhas?

Lembre-se de que a barreira cultural é a maior barreira a ser quebrada.

Um dos grandes alvos da adoção de micro serviços é a independência no deploy. Então, se a cultura é ter janelas de deploy para produção, vocês já tem um grande trabalho cultural pela frente.

Fazer um sistema distribuído não é fazer um blog com Rails. Existe uma grande quantidade de técnicas e tecnologias novas para além da famigerada arquitetura de 3 camadas que devem ser dominadas para a adoção da arquitetura de micro serviços.

Meu time tem os skills necessários?

Fundamental: colaboração, comunicação e conhecimento do negócio.

Refatorar base de dados. Mensagens distribuídas. Teoria de filas. API Gateway. Protocolos de comunicação além do HTTP. Domain Driven Design. Teorema CAP. Profiling de aplicações. Service discovery SQL vs NoSQL. A importância dos logs em um modelo distribuído. Correlation ID. DevOps. Testes baseados em contrato. IaC. Linux containers. Swagger. Continuous Delivery. Stateful vs. Stateless. Graceful shutdowns.

Se o seu time não entende no mínimo 80% do termos descritos, me parece que tem um GRANDE trabalho de estudo antes de se meter em apuros.

Seu time já sabe fazer um monolito?

Se seu time ainda não sabe fazer um excelente monolito, o que te faz pensar que vocês conseguirão fazer a mesma coisa, dessa vez, de forma distribuída?

Você já consegue olhar para o seu sistema monolítico e identificar as diversas áreas de negócio?

O core business está coberto por testes descritivos o suficiente que sirvam de documentação? Estão cobertos também os casos conhecidos de exceção?

O quão fácil é remover uma funcionalidade sem quebrar o sistema?

Que problemas serão resolvidos com essa arquitetura e que novos problemas serão assumidos?

O que pode ser feito com essa arquitetura que não seria possível com a monolítica?

O time já sabe a vazão do sistema atual para justificar a possível alta disponibilidade no modelo distribuído?

Em troca da disponibilidade alta seu time já sabe lidar com transações distribuídas?

Quando existe uma mudança, é fácil observar que sistemas ou clientes são afetados?

Como eu garanto que o serviço que depende do sistema atual (que o time não tem domínio de como foi implementado) vai continuar funcionando após uma mudança?

Ainda é preciso fazer um acesso via SSH para ver logs da aplicação?

Conclusão

Sejam quais forem as respostas, tenha em mente que o seu time tem que conseguir ser mais eficiente na velocidade de entrega e nos custos mantendo o sistema altamente disponível.

Nos próximos textos pretendo atacar essas perguntas e dissecar os temas para uma visão clara de como lidar com os desafios.

Tem algum ponto que gostaria de discutir? Comente ou mande uma mensagem no twitter: @alextrending.

A normalização do desenvolvimento medíocre de software

Alex Rios — Sat, 14 Dec 2019 04:14:50 +0000

Há 19 anos a Microsoft já sabia como fazer interfaces melhores do que 90% dos sistemas que são criados hoje em dia.

Inductive User Interface é relevante ate hoje, mas continua não sendo adotada pela desculpa mais comum entre empresas e profissionais da área de tecnologia: falta de tempo.

Isso me faz pensar que uma coisa vai levando a outra; Modelagem anêmica e o pensamento que tudo seria um grande CRUD.

Técnicas como Event Storming podem trazer para superfície a jornada do usuário no sistema. Essa jornada permite a utilização de task based actions na UI. Uma vez que as intenções do usuário são bem mapeadas, o sistema já esta um passo mais próximo de introduzir arquiteturas como CQRS e Event Sourcing.

Sua empresa tem um churn grande, pois os usuários não entendem como usar o sistema?

É possível obter um relatório de algum momento do passado do sistema?
Quer fazer machine learning com os dados, mas o que se tem sempre o estado atual do seu domínio (ou seriam apenas DTOs serializados numa base SQL?)

Enquanto fazer da melhor maneira possível for considerado “demorado”, “devaneio arquitetural” e “cerimônia hipster”, tempo continuará sendo o melhor argumento para entregas medíocres.

Se liga: MVP não é para sempre!