domingo, 29 de abril de 2018

Como eu conquistei a certificação PSM I

Passos para conquistar a certificação PSM I da Scrum.Org

Esse mês de abril foi bem corrido. Além do curso de CI e CD da 4linux (que recomendo bastante), foi o mês que conquistei a certificação PSM I da scrum.org com nota de 96,3% Essa certificação é classificada como nível intermediário, mas, após seguir os passos abaixo, você vai classificar sentir uma segurança e facilidade extrema no momento da prova.

Material de estudos

Utilizei como fonte de estudos o curso preparatório para a certificação PSM I da TI Exames. O curso possui 18 horas distribuídas em alguns módulos (link do curso). Possui simulados e comentários de aprovados com recomendações de estudo.

Antes de iniciar o curso, resolvi fazer um simulado para entender onde eu estava e o quando eu precisava me dedicar para ter 100% de segurança no dia da prova (e não adiantou, fiquei nervoso do mesmo jeito rsrs). No simulado que fiz, antes de iniciar os estudos, fiquei com 60% (precisa de 85% para ser aprovado). Bom, essa é minha primeira recomendação: Não faça essa cagada etapa. Tentar medir meu conhecimento só serviu para que eu ficasse nervoso até ter finalmente feito a prova e ter sido aprovado. Foi uma estupidez. Eu sou ansioso e isso só piorou as coisas. Então, estude o material da TI Exames antes de fazer qualquer simulado.


Scrum guide

Leia no mínimo uma vez o scrum guide. É um PDF de 19 paginas. Eu li em uma noite, em torno de uma hora você consegue ler ele por completo. Essa etapa é recomendada por muitos que tiraram a certificação. Por mais que muitas das questões sejam situacionais, ou seja, será apresentada uma situação e a partir dos seus estudos você deve indicar qual a melhor resposta para aquela situação (então é normal muitas das questão terem mais de uma alternativa verdadeira - a correta será a que é melhor aplicada na situação em questão).

A leitura do scrum guide permite que você entenda os princípios do scrum e os motivadores, auxiliando para que você não falhe nas questões com mais de uma alternativa verdadeira.


Simulados, simulados e mais simulados

Concluindo o material de estudos e a leitura do scrum guide, é hora de fazer simulados até não querer mais olhar para eles. Uma recomendação que li nos comentários de um dos alunos da TI exames é que eles façam os simulados até atingir uma média de 95% em todos os simulados. Ou seja, a dica aqui é fazer simulados até sua pontuação atingir 95% em todos os simulados

Ah, a scrum.org tem um simulado com 30 questões básicas sobre scrum. Se você não gabaritar esse simulado, nem pense em tentar a certificação.


Anotações

Por fim, após todas as etapas anteriores, eu recomendo fazer anotações. Anote tudo aquilo que errou nos simulados e leia novamente o assunto. Anote também tudo aquilo que tem dúvidas ou que você acredita ir em desencontro com qualquer outro ponto dentro do scrum.

Escrever ajuda a memorizar. Veja como eu fiz:






sábado, 28 de abril de 2018

Aula de Desenvolvimento de Software

Montei o cronograma, apresentamos a proposta, montamos a turma e foi um sucesso.


Gusteau no filme "Ratatouille" dizia: Qualquer um pode cozinhar. Eu digo: Qualquer um pode programar... E foi com base nessa crença que planejei, montei um cronograma e abrimos a oportunidade para que qualquer pessoa na empresa, pudesse se inscrever para participar do treinamento de desenvolvimento de software com C# .Net.

É de conhecimento de muitos que tenho buscado uma oportunidade para colocar em pratica um projeto social para dar aulas de programação para crianças (a partir dos 12 anos +-), porém estamos no Brasil e nem todo mundo tem interesse em apoiar um projeto sem fins lucrativos. Um projeto que o objetivo é apenas ensinar por ensinar.

Expondo esse meu interesse, a empresa onde trabalho resolveu organizar um projeto para aplicarmos isso internamente. Sem nenhum objetivo, apenas para dar oportunidade para pessoas de áreas totalmente aleatórias, de conhecerem e praticarem programação de software.

O projeto

A primeira etapa do projeto, foi montar um cronograma. Eu já tinha um montado para o projeto das escolas, mas precisava adaptar pois não iria mais ensinar crianças de 12 anos, mas sim profissionais de áreas diversas (e foram diversas mesmo rsrs). Basicamente retirei exemplos onde utilizo jogos como MineCraft, Roblox e outros para explicar sobre comunicação entre cliente e servidor, ou apps como WhatsApp e Facebook para explicar estruturas básicas destes softwares, como também removi alguns pontos onde demonstro e sugiro jogos para praticar programação como o Code Combat. Filtrei um pouco o conteúdo e inclui algumas instruções sobre como e porque debugar, e obviamente, usei os softwares da empresa como ferramentas para explicar estrutura, arquitetura e decisões tomadas com base no que negócio (bem como a influência do negócio no produto final).

Caso tenha interesse em aplicar esse projeto na sua empresa, fica ai um exemplo do cronograma base que utilizei: link do google drive


Ok, mas como foram as aulas?

Busquei usar o cronograma como base e eu aumentava ou diminuía a complexidade de acordo com o avanço dos alunos. Passamos por conceitos, esclarecimento de dúvidas, até chegar ao Html, Css, Javascript e concluir com C# usando o padrão MVC do .Net framework MVC. As aulas não foram code, code, code... Para ter uma ideia, eles sabem o que é MVC, o que é um Framework, um servidor web. Eles sabem que a aplicação no servidor entrega um código HTML para ser renderizado no browser (eles sabem o que é renderizado rsrs). Busquei explicar todas essas siglas e nomenclaturas que para nós que somos de desenvolvimento de software é algo tão comum como colocar a roupa depois de sair do banho. O resultado foi satisfatório. No final, entreguei na mão deles classes e views fora de um projeto (dentro de um arquivo rar) e eles tiveram de criar um projeto usando Visual Studio 2017 (empty + MVC - expliquei que NUNCA devem usar o template MVC por montar um projeto com muita coisa que provavelmente não usaremos. Então usar um projeto em branco e configurar tudo foi a abordagem que usaram, e fizeram isso perfeitamente bem). O modelo do projeto utilizado eu disponibilizei no GitHub

Obviamente eu não iria apenas entregar classes para que eles montassem um projeto. Isso seria simples. Eu entreguei classes com diversos erros e bugs. Então, além de construírem o projeto, eles tiveram de tratar os bugs, debugar, ler o stacktrace, identificar onde estava o problema e corrigir. E sinceramente, eu fiquei impressionado com o resultado. Se não me engano foram 12 horas de curso. Conseguimos um resultado muito bacana. A cada aula eu buscava entregar dicas no grupo de e-mail que criamos, matérias para que eles pudemos compreender mais o que discutimos naquela aula. E no final, enviei alguns cursos gratuitos para que eles seguissem com os estudos.

O Code School tem algumas opções interessantes para auxiliar quem está iniciando. E obviamente o queridinho de todos, o Udemy.

No LinkedIn é possível ver um pedacinho do que rolou por lá.



Então é isso. Termino por aqui reforçando o que falei no início desta postagem: Qualquer um pode programar!.

Bônus: Ah, de quebra arrecadamos doações para a APAE de São Caetano do Sul :)

domingo, 15 de abril de 2018

Programação assíncrona, async e await e conceitos

Cada vez mais estamos utilizando o conceito de programação assíncrona. Agora com as facilidades do async e await presentes desde do .Net Framework 4.5, podemos melhorar a experiência do usuário com pequenas alterações no nosso código.

Não pretendo explicar muito sobre isso pois muitos outros já fizeram isso. Como esse artigo bem esclarecedor no site da Microsoft ou até mesmo, esse outro do Marcoratti.

Então, mão na massa

Nesse primeiro caso, quero exemplificar uma situação comum, onde precisamos executar nosso Action e dentro do Action quero executar uma ação que não impacta na UI, mas que deve ser executada (um registro de log, por exemplo). Então, ao invés de:




Perceba que o tempo de resposta é pouco mais de 10 segundos. Porque? Porque o método TrabalhoQuePrecisaExecuta(), rodou na mesma thread que as outras operações. E quando fazemos isso, estamos enfileirando as execuções.

Podemos fazer isso (vale lembrar que não precisamos do async e await para usar essa abordagem. O que estamos fazendo aqui, é apenas isolando nosso código em uma thread a parte):


Perceba que o simples fato de jogar o TrabalhoQuePrecisaExecutar() dentro de um Task.Run, deixamos de enfileirar esse processamento e nosso Action simplesmente passou por por essa operação, mandou executa-la em outra thread e seguiu com nosso código.

Mas e quando eu quero que meu método async retorne algo para a UI?


Bom, vamos pensar... Se eu quero que um método que está em outra thread, retorne algo para minha UI, eu preciso obrigatoriamente, esperar esse método carregar e fatalmente vou cair na mesma situação exposta no primeiro caso:




Ué, então não existe mágica?

Não existe :( 

Mas, existe o conceito de estratégia, em grego strateegia, em latim strategi, em francês stratégie...

O que sabemos?
- Se jogarmos nosso código em uma thread separada, isolamos o processamento. 
- Se usarmos o Result, podemos recuperar o retorno (isso causa block).

Então, se eu deixar meu código dentro de uma thread logo no início (sabendo que ele demora para executar), seguir com o processamento e pedir o resultado da thread no final, vou "processar em paralelo e reduzir o tempo de resposta". Assim:


Lol, faz sentido O.o !

Mas, e onde entra o async e o await em toda essa história?

Certamente você leu o artigo do Marcoratti e da Microsoft que coloquei no inicio do post (eu sei que você nem clicou), então, deve ter percebido que o async e o await, permitem que eu execute Tasks uma após a outra, mas ainda em paralelo. O próximo teste, usar o código acima, mas vou chamar o método TrabalhoQuePrecisaExecutar() 2 vezes dentro de uma outra thread e utilizar o async e await para paralelizar as duas execuções e somar os retornos. E a thread principal, no result (que vai bloquear a execução na thread principal), vai pegar a soma dessas duas operações. ou seja:



Nos exemplos onde usamos o .Result, perceba que ele tem o mesmo efeito que o await, pois trava o processamento até conseguir recuperar o retorno da thread.

Para colher todos os frutos dessa abordagem, é interessante trabalhar com esse backend em aplicações SPA. Assim podemos utilizar chamadas assíncronas (com ajax) sem bloquear a UI do usuário em momento algum.

Nos exemplo acima, a partir do momento que usamos um controller e um action para retornar os dados em uma View tradicional, estamos bloqueado, porém, usando algumas abordagens para otimizar o tempo de resposta usando os conceitos de programação assíncrona.

Dentro de um controller, por vezes somos obrigados a chamar alguma API externa e acabamos por cair nessa situação. Para essas situações onde a requisição é síncrona e uma implementação dentro dela necessita de uma chamada assincrona, usamos o .Result para garantir o retorno. Não é o melhor cenário, mas para essa situação, em implementação pontual, resolve sem ter de refatorar toda a aplicação.