Aprendendo com Coding Dojo

Todo aquele que precisa executar uma prática que exige conhecimento de movimentos específicos para alcançar resultados esperados, tem que ter um espaço seguro e confiável para treinar e aplicar cada movimento, seja novo ou conhecido e além de ter um ou mais mestres para orientar e também avaliar a performance da aplicação do aprendizado. Tá, mas o que isso tem há ver com tecnologia? Tudo meu pequeno padawan, os desenvolvedores também precisam ter um espaço seguro e confiável para treinar e melhorar suas habilidades, esse local é Coding Dojo.

A palavra Condig é o termo em inglês para “programando” ou “gerando código”, já a palavra Dojo, (pronuncia-se Dojô) é uma palavra de origem japonesa e significa “local de treinamento”. Logo, o Coding Dojo nada mais é que do um “local de treinamento de código”.

Esse espaço tem como suas principais características ser um ambiente colaborativo, que estimula o aprendizado de forma divertida e principalmente sem nenhum tipo de competitividade entre os participantes. Existem três modalidades:

Randori

Esse é o formato mais “tradicional” por que todos participação, no início o mestre da sessão propõem um desafio a ser resolvido e todos os participantes deverão resolvê-lo utilizando uma única máquina, utilizando o sistema de rodízio de pares. Neste par existirá um piloto que irá operar a máquina e o copiloto que irá auxiliá-lo, a plateia neste momento só acompanha, a cada tempo de minutos pré-definidos previamente, o copiloto virá piloto e alguém da plateia se torna o co-piloto. Se utilizado o TDD a plateia somente poderá efetuar interrupções quando todos os testes estiverem verde. Importante, o mestre pode servir como um consultor da tecnologia e não dá solução do problema. Ao final todos devem entender a solução, pois durante toda a sessão o piloto e copiloto devem estar sempre narrando seus pensamentos.

Kata

Aqui o mestre assume a postura de palestrante, ele irá demonstrar o problema e já partir para aplicação da solução, que pode estar parte pré desenvolvida e ser complementa durante a sessão. Todos os participantes podem a qualquer momento efetuar interrupções para expor dúvidas. O resultado final é que todos ao final devem ser capazes de efetuar a implementação da solução. 

Kake

Muito parecido ao Randori, a principalmente diferença é que não existe um rodízio de pessoas, e sim de duplas, cada dupla trabalha em sua máquina e ao fim do turno as duplas trocam de máquinas e continuam o desenvolvimento da dupla anterior, esse ambiente exige mais conhecimento avançado da tecnologia ensinada.

Benefícios

A utilização do Coding Dojo em um ambiente corporativo aumenta o engajamento do time de desenvolvimento, estimula a aquisição de novos conhecimentos e principalmente desenvolve os valores dos profissionais participantes:

• Participação: Exemplifica a importância da participação de todos na resolução do problema, porque todos podem opinar.

• Cooperação: O problema tente a ter uma solução melhor e mais rápida com a colaboração entre todos, pois vários aspectos são levados em conta por conta da experiência pessoal de cada participante.

• Coragem: Estimula a coragem de enfrentar novos desafios, pois o ambiente sendo seguro até o mais tímidos ganham espaço e oportunidade para praticar a interlocução de suas ideias, sem o julgamento do dia a dia.

• Simplicidade: Como existem vários níveis de experiências entre os participantes, a simplicidade é importante ser mantida para que todos estejam avançado em conjunto, porque é vital que ao final todos estejam treinados para implementação a solução.

• Respeito: Esse valor é muito praticado, porque todos os participante devem respeitar a proposta de solução de um problema, porque todos acabamos aprendendo que existem várias formas de resolver um problema.

Sempre ao final do Coding Dojo é importantíssimo a execução de uma breve retrospectiva pelo responsável para verificar se os principais objetivos foram alcançados, porque além de ser ambiente de ensinamento seguro, é também altamente adaptável ao público, ou seja, caso os resultados não estejam sendo satisfatório, podemos adaptar o formato para facilitar a aplicação do conhecimento.

Onde Treinar?

Aqui na GFT praticamos a cada 15 dias em sessões online, elas são abertas para todos participarem, basta acessar o atalho abaixo, escolher o melhor dia e horário para você praticar conosco.

https://www.meetup.com/GFTBrasil

Oss

Marcelo Goberto de Azevedo 

Arquiteto na GFT Brasil

//marcelogoberto.com.br

Principios SOLID em Imagens

A maioria dos desenvolvedores utilizam a POO - Programação Orientada à Objeto e devem ter ouvido falar sobre SOLID, essa sigla é acrônimo para (iniciais do nome em inglês) para os principios para construção de software com qualidade e manutentabilidade. 

Para facilitar a compreensão desses conceitos, foi criado as imagens abaixo, afinal de contas nada melhor que desenhar para se fazer entender.

Princípio da responsabilidade única - (Single-responsibility principle)

Uma classe, microsserviços, componentes devem ser responsável por apenas uma atividade. Utilizando esse principio você poderá garantir que qualquer alteração que venha a acontecer no código irá impactar somente seus dependentes diretos. 

Princípio aberto-fechado (Open–closed principle)

As entidades de (classes, módulos, funções) devem estar abertas para extensão, entretanto  fechado para modificação. Utilizando esse principio podemos garantir que as alterações sendo realizadas através de extensão da entidade base nada será afetado no contexto dos códigos que utilizam a classe original. 

Princípio da substituição de Liskov (Liskov substitution principle)

O objetivo desse princípio é verificar que uma subclasse poderá ser substituída pela sua classe base sem erros. O principio é uma homenagem a Barbara Liskov, ela definiu que "se S é um subtipo de T, então os objetos do tipo T, em um programa, podem ser substituídos pelos objetos de tipo S sem que seja necessário alterar as propriedades deste programa".

Princípio de segregação de Interface (Interface segregation principle)

Crie interfaces refinadas e específicas, porque elas são melhores que interfaces genéricas. Não devemos ser forçados a depender das interfaces que não iremos utilizar. Esse princípio lida com as desvantagens da implementação de grandes interfaces únicas.

Princípio da inversão de dependência (Dependency inversion principle)

Chega um momento no desenvolvimento de software em que nosso aplicativo será amplamente composto por módulos. Quando isso acontece, precisamos esclarecer as coisas usando a injeção de dependência. De uma forma objetiva o princípio nos faz entender que sempre devemos depender de abstrações e não das implementações.

Todos os desenvolvedores devem seguir esses cinco princípios, porque eles irão garantir um código mais limpo, eficiente e mais fácil de ser testado.

Marcelo Goberto de Azevedo

Arquiteto na GFT Brasil

//marcelogoberto.com.br

As imagens são traduções das orignais do artigo de Ugonna Thelma em https://medium.com/backticks-tildes/the-s-o-l-i-d-principles-in-pictures-b34ce2f1e898

Enviando o Resultado de uma Consulta SQL em formato HTML via Logic App

É um requisito bem simples, você precisa que um resultado de consulta ao banco de dados, ou seja, uma saída direta de uma tabela ou um resultado retornado de procedimento precisa ser enviado por email. Esse e-mail pode ser um retrato do momento da execução, algumas verificação diária de um processamento ou simplesmente uma notificação de algo que não deveria ter acontecido. E para facilitar o entendimento enviaremos o resultado formatado em HTML.

Existem inúmeras maneiras mais ou menos eficazes de realizar essa atividade, essa é uma forma de exemplificar um processo simples e rápido de ser implementado.

Consulta SQL

Suponhamos que precisamos enviar uma listagem dos produtos mais vendidos nos últimos sete dias e para isso criamos a consulta abaixo:

Abaixo fazemos pequenas adaptações na consulta, para formatar o resultado para que seja enviado por email e tenha um visual mais legível.

1. Aplicamos a tag <li> a tag para listar todos os registros de conjunto de dados

2. Em seguida, envolvemos a lista de itens com a tag HTML <ul>.

O resultado da consulta não é visualmente bonito, já o resultado em HTML :-)

Azure Logic App

Agora vamos criar o nosso Logic App com um gatilho recorrência, a execução da consulta e uma ação "Enviar um e-mail"

Gatilho

Vamos programar para que o aplicativo execute diariamente às 20h.

Ação

Para facilitar vamos executar diretamente o comando SQL, entretanto poderíamos optar por executar um procedimento. Importante configurar o método de autenticação.

Resultado

Agora basta selecionarmos a plataforma que irá efetuar o disparo do email, neste caso está configurado o disparo por uma conta do Gmail. Além da possibilidade de adicionar texto extra ao corpo do email, podemos ainda utilizar fórmulas para coletar outras informações.

Importante, como o resultado de uma consulta pode ser mais de uma linha, essa ação criará um laço que será executado para cada linha, entretanto nossa consulta sempre irá retornar somente uma linha, logo somente um email será disparado.

Execução 

Após a execução podemos verificar se as etapas foram concluídas com êxito e tempo de execução.

Checando o Email

E podemos ver o e-mail que será entregue todo dia, uma forma simples para atingir um objetivo. 

Até a próxima! :-)

Marcelo Goberto de Azevedo 

Arquiteto na GFT Brasil

//marcelogoberto.com.br