Educação hoje, amanhã e sempre.

Investir na própria educação é o melhor investimento que você pode fazer na vida. Quanto mais você investir, mais rápido terá retorno.

Dando continuidade aos posts sobre carreira e educação eu gostaria de chamar a responsabilidade do desenvolvedor para o papel que ele desempenha.

Trabalhar com desenvolvimento de software hoje em dia é um mar de tranquilidade, existem mais vagas em aberto do que profissionais para preenchê-las. Por um lado isto é bom, de outro lado é péssimo.

O lado bom é que desenvolvedores que entregam algum resultado não ficam desempregados (dá para trocar de emprego a cada semana se quiser). Isto é sinal da falta de profissionais qualificados para atender a demanda crescente em desenvolvimento de software.

Para um desenvolvedor ficar desempregado (por meses) é sinal de que ele está muito defasado em relação ao mercado ou existe algum fator que está complicando demais sua contratação (valor hora / localização / condições especiais).

O lado ruim da demanda de empregos ser maior do que o número de profissionais disponíveis

É simples de entender, num cenário de escassez tudo passa a ser supervalorizado. Vamos fazer uma analogia com a escassez de combustível que tivemos pouco tempo atrás. O que aconteceu? Tivemos postos de gasolina vendendo combustível adulterado por R$ 10 o litro, absurdo? Havia filas de carros para abastecer (mesmo cientes da supervalorização e da baixa qualidade).

O problema de uma alta demanda de oportunidades é que isto gera um comodismo profissional, os desenvolvedores não precisam se preocupar em correr atrás de aperfeiçoamento técnico para garantir os seus empregos.

Pessoalmente eu já ouvi inúmeras vezes a seguinte frase:

Acabamos contratando o menos pior por que estamos precisando urgente! Tivemos diversas entrevistas mas não apareceu ninguém dentro do perfil que esperávamos contratar.

Em algumas profissões supersaturadas como Administradores, Advogados e etc. A situação é inversa! Além da graduação é necessário ter Pós, MBA’s entre diversos outros itens no currículo para conseguir uma boa oportunidade.

Mas nem tudo permanecerá da mesma forma para sempre, os advogados, administradores e etc já tiveram também sua época de ouro.

Existe uma geração de novos desenvolvedores chegando, eles são muito mais jovens, muito mais dispostos e aceitariam sua vaga pela metade do seu salário.

Parece uma profecia exagerada né? Eu posso confirmar algumas verdades sobre o assunto. Eu tenho muitos alunos de 17, 18, 19 anos que já dominam completamente as tecnologias atuais de mercado e conseguem entregar software com uma boa qualidade. Eles não possuem casa, filhos e contas para pagar. Eles aceitam oportunidades pelo desafio e estão em busca de experiência e não de bons salários.

Por incrível que pareça são os mais jovens que fazem mais cursos comigo, e apesar de requerer um investimento financeiro para isto (as vezes nem empregados estão) eles fazem questão de investir, eles realmente valorizam o conhecimento e estão se preparando para entrar e crescer no mercado.

58% dos brasileiros não possuem gestão financeira.

O que este número alarmante tem a ver com o assunto? Tudo!

O ideal é que todo trabalhador poupasse 40% de seu salário e que investisse 10% em sua educação / cultura. Isto está longe da realidade e muitas vezes as pessoas alegam negligenciar a própria educação por questões financeiras.

Seria por questões financeiras ou por caos na gestão financeira?
Concordo que o custo de vida em nosso país é altíssimo, mas tudo é uma questão de prioridades. Uma calça de marca, um jantar a dois em um bom restaurante não sai por menos de R$ 150,00 e cientes disto nós pagamos sem nos espantar.

Por que pagar R$ 150,00 em um livro / curso / evento aparenta ser um gasto muito maior? Provavelmente porque em questão de prioridades a educação aparenta ser um custo e não um investimento. Prazer em comer bem, usar roupas de marca e até mesmo possuir um bom carro é mais importante do que investir em seu futuro? Olhando por esse lado com certeza você respondeu não!

Investir em educação nem sempre significa investir dinheiro. Significa investir tempo e dedicação. Existem milhões de ótimos conteúdos gratuitos disponíveis, basta buscar.

Vou lhe propor um exercício / desafio, responda sinceramente a esta lista:

  • Você está satisfeito com o que ganha?
  • Seus planos futuros são suportados pelo seu salário atual?
  • Você se considera tecnicamente capacitado para ocupar uma vaga superior a sua?
  • Quantas horas você estuda por semana?
  • Qual o percentual do seu salário investido na sua educação?
  • Onde você se vê daqui 5 anos?

Estas respostas irão lhe ajudar a criar um plano e rotina de gestão financeira e estudos para que você possa alcançar seus objetivos. Tudo depende de você e de quão longe pretende chegar.

Um outro ótimo exercício é buscar a “vaga dos sonhos”, analisar a descrição da vaga, o que ela exige do profissional e criar um plano para conseguir atender a expectativa dessa vaga.

Espero ter lhe ajudado! Caso tenha alguma história ou comentário a fazer utilize o formulário abaixo:

Versionamento de APIs com WebAPI + Vídeo Aula

O versionamento de APIs é uma estratégia para implementar rapidamente mudanças e novas funcionalidades em seu negócio.

O ASP.NET Core WebAPI possui suporte nativo para versionamento de APIs. Além de facilitar a implementação, este suporte entrega outras facilidades como informar as APIs obsoletas via Header do Response e também expor informações importantes para a documentação da API.

Por que você deve versionar sua API?

Todos os desenvolvedores precisam entender que não existe condições de uma empresa evoluir e ser competitiva no mercado se ela não conseguir entregar rapidamente as soluções que o mercado precisa! Mudanças ocorrem muito rápido e você é o responsável por entregar soluções que permitam serem adaptadas rapidamente aos novos cenários.

Gostaria de contar uma história que aconteceu recentemente comigo (fatos 100% reais). No mês passado eu encerrei uma parceria de muitos anos com uma empresa de software que fornecia soluções para um de meus negócios.
De forma amigável eu enviei um e-mail para o CEO avisando de minha decisão, agradecendo pela parceria e desejando que a empresa dele não parasse no tempo devido aos processos burocráticos de mudanças que eu e os demais clientes enfrentavam.

O CEO me respondeu com um e-mail enorme e triste, contando das dores em atender mudanças simples, que 3 anos atrás havia investido praticamente todo o budget da empresa para desenvolver um software que hoje não suporta novas implementações sem um processo enorme de mudanças e burocracias internas.

O desenvolvedor além de entregar software, também é parte responsável pelo sucesso ou fracasso do negócio.

Como o versionamento de APIs pode ajudar o seu negócio a ser mais competitivo

Vamos supor que você entregue um conjunto de funcionalidades em sua API e com o passar do tempo novas mudanças e funcionalidades são exigidas, porém implementar estas necessidades em seu código resultam em breaking changes no lado do cliente.

Você pode considerar tudo que tem entregue até hoje como a V1 da sua API e implementar as novas funcionalidades como uma V2, sendo assim:

Os clientes que precisam urgentemente das novas funcionalidades poderão ser atendidos rapidamente por sua empresa, basta implementar a V2 da sua API. Os clientes que não possuem tanta necessidade de mudança continuam usando a V1, porém passam a receber o aviso que esta API está obsoleta e será desativada em algum tempo (por exemplo 6 meses).

Você passa a atender o negócio de forma ágil, facilitando a vida dos clientes que precisam rapidamente das novas funcionalidades e sem prejudicar aqueles que não precisam.

Quando é hora de versionar minha API?

Considere o versionamento da sua API necessário toda vez que uma mudança resultar em breaking changes do lado do cliente.

E claro, para prever com exatidão os breaking changes é necessário escrever uma diversidade de testes de integração que simula os inúmeros cenários de consumo da sua API do lado do cliente.

Como implementar o versionamento da minha API?

Esta é a parte mais fácil 🙂 O ASP.NET Core dá suporte nativo ao versionamento, além de facilitar muito na documentação (via Swagger por ex).

Documentação oficial:
https://github.com/Microsoft/aspnet-api-versioning

Assista esta aula gratuita do meu curso REST com ASP.NET Core WebAPI

O desenvolvedor.io é a minha nova plataforma de cursos online e já temos mais de 12 cursos anunciados, o curso sobre ASP.NET Core Web API está 100% entregue e possui diversas aulas gratuitas para você experimentar e aprender um pouco mais com nosso conteúdo.

Para aprender a implementar na prática o versionamento de APIs assista esta minha aula gratuita:

Espero que aproveite este conteúdo e comece desde já a planejar e se preparar para esta estratégia que pode ser um grande diferencial em seu negócio.

Vamos continuar enriquecendo o assunto utilize os comentários abaixo e deixe sua contribuição 🙂

Qual é a característica mais importante que um programador deve ter?

Escrevo este post motivado por algo que venho falando faz muito tempo e também em resposta a um debate que tive entre colegas num grupo privado de uma comunidade.

O assunto a seguir pode ser incômodo, pode gerar um desconforto e até mesmo pode ser que você não concorde comigo, porém acredito que é necessário voltar a falar do assunto.

Uns dias atrás em uma das diversas comunidades que participo, um rapaz iniciante na área perguntou:

Qual é a característica mais importante que um programador deve ter?

Eu parei para refletir e estruturar uma resposta para o rapaz, então eu refleti… refleti… refleti… quando me dei conta eu passei mais de 10 minutos pensando no assunto e não tinha uma resposta pronta para dar.

Foi nesse momento que eu parei e pensei:
– Vamos mudar um pouco, vamos pensar de uma outra maneira.
Então e eu me fiz a seguinte pergunta:

Qual é a pior característica que um programador pode ter?

Incrível! Ficou mais fácil, eu realmente consegui chegar numa opinião e gostaria de dividir com você!

A resposta rápida é:

A pior característica que um programador pode ter é a falta de humildade em reconhecer que ele não sabe de tudo e nem é perfeito naquilo que faz. Sempre tem como melhorar!
A melhor característica que um programador pode ter é o comprometimento em sempre buscar o aperfeiçoamento técnico!

Acho que este pensamento é bem claro (até simples demais) e fala somente a verdade sem ofender ninguém. Pode ser que você discorde, talvez exista algo mais importante? Talvez! Mas para mim esta é a base fundamental:

Buscar conhecimento > aprender > aplicar > analisar > criticar > aperfeiçoar

Repetir este processo sempre, não importa em qual patamar da carreira você chegou!

Humildade e uma visão do “mundo real”

A seguir transcrevo o diálogo original em que participei com um grupo de colegas do qual eu defendo uma questão de humildade e visão de realidade, fiz o papel de “advogado do diabo” na conversa, pois precisava entender melhor as afirmações do colega.

[colega]Se você não sabe arquitetura de computadores. Análise de complexidade e Estrutura de dados. Não é programador. É um amador remunerado. Se aprendeu na faculdade ou fora, tanto faz. Mas TEM QUE SABER.

[eu]Então se a pessoa entrega software que funciona e atende o cliente, mas não sabe disto, então não é um programador?

[colega]EXATAMENTE. Você não entrega software que funciona sem saber estrutura de dados.

[eu]Tem certeza?

[colega]Tenho! Você não escreve software que escala. Nem que não escala. Você entrega uma colcha de retalhos baseada em um framework que você não entende. Isso não é ser profissional!

[eu]E como você pode garantir que uma pessoa que não sabe fazer uma análise de complexidade não entrega software que escala?

[colega]Simples. Por que não escala. Se você não sabe nem me dizer como seu algoritmo vai se comportar quando aumentar o número de elementos que ele tem que tratar. Certeza que na maior parte das vezes vai se comportar mal.

[eu]Ele pode usar uma ferramenta de analise de performance, testes de carga e depois pesquisar como fazer melhor, enfim… Eu que não vou ter a “audácia” em falar que 70% dos programadores são amadores remunerados, só isso…

[colega]Não falei em percentual. Mas, sendo realista, esse número é bem maior.


O assunto foi além deste ponto, mas divagou um pouco, o que realmente me importa está nesta troca de mensagens que transcrevi.

Mais uma vez deixo claro que as afirmações (ou taxações) não eram para a minha pessoa, eu entrei no meio de uma conversa já iniciada apenas para fazer o “advogado do diabo” e entender melhor as sérias colocações feitas pelo colega, no final sugeri tratarmos disso em público para cada um expor sua opinião.

Realmente não existe maneira de discordar que estes conhecimentos são fundamentais e muito importantes, porém eu acho extremamente errado rotular praticamente todos os programadores de “amadores remunerados” uma vez que entregam software, fazem escalar, fazem otimizações e por final atendem o cliente (mesmo usando ferramentas ao invés de puro conhecimento de ciência da computação).

Humildade em reconhecer nossas limitações / deficiências é fundamental, assim como é importante ter humildade em reconhecer que existem diversos tipos/níveis de profissionais com focos diferentes no mercado.

Hoje em dia podemos dizer que a maioria dos programadores são programadores em frameworks:
(.NET, Java, Angular, React, MVC, ASP.NET etc, etc…)

São frameworks / bibliotecas desenvolvidas por pessoas que sabem muito mais do que a grande maioria dos programadores do mercado. Estes programadores do mercado utilizam IDE’s inteligentes, ferramentas de análise de código, testes de penetração (segurança), testes de carga e enfim.

Programadores utilizam tecnologia para entregar tecnologia, é uma realidade e nem por isto você deve aceitar que alguém lhe chame de amador por que existe uma forma de executar algumas tarefas sem a necessidade de uma ferramenta específica.
Eu apenas lhe recomendaria que um dia se dedicasse a aprender como fazer isto.

Antigamente era necessário ter muito mais cuidado em não esquecer de desalocar um ponteiro por exemplo, mas ai vieram os frameworks que gerenciam as pilhas Stack / Heap, que fazem uso de garbage collector, que otimizam o código naturalmente durante a compilação e executam de forma inteligente e etc.

Isto não significa que você não deve cuidar do código para evitar uma StackOverFlow Exception por exemplo, nem deixar de analisar se o seu algoritmo está performando bem (assim como as consultas em banco). Tudo isso AINDA É OBRIGATÓRIO. Porém cabe no que eu citei acima:

Buscar conhecimento > aprender > aplicar > analisar > criticar > aperfeiçoar

Você deve SEMPRE se preocupar com que está entregando, pois isto vai evitar custos desnecessários de infra, manutenções emergenciais após problemas de escala e etc, pode custar até mesmo o seu emprego. Portanto faça como você puder, use as ferramentas! Mas também estude mais para poder não depender 100% delas, porém NUNCA deixe de fazer o seu melhor!

Sobre ter humildade em rotular pessoas e medir todo profissional com a mesma régua, eu me recuso a fazer, eu deixo isso por conta do mercado e o mercado cuida disso de uma forma simples:

  • Aplica exames técnicos de contratação
  • Divide o profissional em níveis (ex Junior, Pleno, Sênior)
  • Sabe quando procurar um especialista ou um programador que entregue aquilo que se espera.
  • Realiza avaliações de 360º e fornece feedback.

O mesmo colega da conversa acima já me criticou pelo meu projeto de referência o Equinox Project, pois na visão dele o projeto influenciava os desenvolvedores a utilizar técnicas complexas para fazer um simples CRUD.

Eu acredito que o programador (prefiro o termo desenvolvedor) deve ser maduro e autônomo o suficiente para tomar suas próprias decisões, não podemos ser paternalistas ao ponto de evitar de entregar conhecimento por que ele pode ser entendido de forma errada, é absurdo!

Obviamente eu não recomendo utilizar toda complexidade do Equinox Project para entregar um CRUD, inclusive esclareço isto na própria documentação do projeto, até por que não é necessário entregar um projeto completo (que justifique a complexidade aplicada) só para conseguir compartilhar um pouco de conhecimento com nossos amigos programadores correto?

Observe esta imagem.

Observe no canto esquerdo inferior a frase:

Entenda tudo isto, mas aplique apenas o que precisar.

Eu achei impressionante a capacidade e simplicidade do autor ao recomendar o uso da complexidade apresentada. Tem a minha admiração.

E aqui entre nós: É o suficiente né?

Não somos meninos com computadores, devemos ser soberanos sobre nossas próprias decisões e eternamente conscientes da busca do constante aperfeiçoamento.

Eu aceito todo tipo de crítica (e adoro receber) mas esta me fez pensar:

“Este meu colega é um excelente profissional, a crítica dele com certeza me faz refletir em fazer mais e melhor, mas acabei de entrar no GitHub dele e encontrei apenas projetos não terminados / com um alto nível de complexidade assim como o meu / pouco documentados. Poxa!
Entrar na fila para criticar é com certeza mais interessante do que estar na fila do fazer/ajudar/compartilhar”.

Este é um post onde exponho as minhas opiniões pessoais, não entenda isto de outra forma. Eu o faço por que em todos os meus longos anos de consultorias e treinamentos eu tratei a todos de forma inclusiva e respeitosa, de outro lado se eu fosse um gestor realizando a contratação de um profissional para esta finalidade eu não aceitaria que as pessoas do meu time fossem expostas a este tipo de rotulação.

Para finalizar…

Acabei escrevendo além do que planejei, mas julgo tudo isto muito importante!

Eu já toquei no assunto neste post: “Quer ser um dos melhores ou vai ficar ai parado?“. Todo mundo tem o seu modelo, a pessoa que você admira e te inspira / influencia. Eu também tenho! E te prometo o seguinte:

  • Nunca irei me colocar como um guru conhecedor da verdade, se você aprendeu algo comigo, ótimo, espero que você faça melhor do que eu fiz inclusive.
  • Nunca irei te julgar como um amador. Se você escreve e entrega software você é desenvolvedor, foque em ser melhor a cada dia, busque identificar suas deficiências e estude para atender melhor os desafios da carreira. Estou aqui para te ajudar inclusive.

Amigo programador:
Desenvolva a melhor característica que um programador pode ter:

Busque sempre o aperfeiçoamento técnico, nunca acredite que algum conhecimento fundamental é dispensável apenas por que você entrega software que funciona.

Ao mesmo tempo busque se policiar para que seus méritos não se tornem motivos de ego e arrogância, pois somos todos eternos aprendizes, cada um ao seu tempo, cada um a sua maneira.

Em tempo, gostaria de deixar mais uma opinião minha sobre o que é ser Programador / Desenvolvedor / Engenheiro / Arquiteto:

Se você tiver algo a compartilhar utilize os comentários abaixo.
Um abraço!

EF Core – Número sequencial customizável.

Criar um número sequencial é simples, mas e se ele tiver que começar de um determinado valor? E se precisar que seja incrementado de outra maneira? Aprenda como fazer!

Utilizar o EF Core facilita muito o processo de desenvolvimento, vamos aprender a configurar uma sequência customizada para evitar configurações extras no BD e deixar mais esta responsabilidade com nossa aplicação.

Neste exemplo vamos supor que possuímos uma classe Pedido e que possui uma propriedade código. Em código nós queremos que esse número inicie em 1000 no banco de dados e que seja incrementado automaticamente de 1 em 1.

O códigos a seguir explicam onde e como fazer esta simples configuração.

Primeiramente configuramos o contexto para criar uma sequencia chamada “MinhaSequencia” que inicia em 1000 e incrementa de 1 em 1.

Na configuração do mapeamento da entidade no EF basta apontar que aquela propriedade vai utilizar uma sequence conhecida:

Basta agora criar a Migration e rodar um “update-database” que estará tudo funcionando perfeitamente.


Vamos continuar a troca de experiências, deixe seu comentário abaixo. Se gostou e concorda com o artigo, compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis.

2018 – Um grande ano de transição e mudanças.

2018 foi um ano intenso, um ano de transição. O início de novos e maiores desafios profissionais e pessoais.

2018 era uma incógnita, ninguém sabia exatamente qual seria o rumo do país, da economia, se era um ano para pisar no freio ou acelerar. Eu resolvi acelerar.

Acredito que muitas pessoas tem o costume de fazer uma lista de metas para o ano que inicia, eu também tenho. O engraçado é que eu fiz tudo diferente do planejado desde que o ano começou.

desenvolvedor.io

Em janeiro de uma hora para outra eu resolvi que não dava mais para controlar a operação da minha empresa de treinamentos do meu home-office. Gravar conteúdos era difícil devido aos horários de silêncio absoluto, infra-estrutura, ar-condicionado e qualidade de vida (madrugar deve ser exceção e não uma rotina). Então busquei um espaço para montar meu escritório / studio de gravação. Encontrei um de 55m² apenas 5 minutos de casa num prédio comercial novo e bem moderno. Fechei na hora.

Faz mais de 3 anos que eu tinha a visão que precisava reestruturar meu negócio de treinamentos, não tinha escala, dependia muito de mim e tendia a ficar obsoleto. Resolvi mudar, mesmo meio que tarde, mas mudei.

Assim nasceu a ideia do desenvolvedor.io que é a minha nova plataforma de treinamentos. No inicio de 2019 será lançada e a meta é fechar 2019 com pelo menos 20 treinamentos completos. Certamente que pretendo ter treinamentos de outros profissionais (alguns em conjunto comigo). É por isso que estou deixando de usar meu nome na empresa e adotei um nome objetivo e fácil de lembrar.

Agora terei espaço para produzir conteúdos e cursos com alta qualidade, poderei transmitir eventos online e também compartilhar este espaço com a comunidade técnica. Poderei alocar confortavelmente uma equipe completa. (financeiro, edição de vídeo, desenvolvimento e etc).

Valeu a pena tanto esforço né? Confira abaixo todo o processo desde o comecinho 😉

DESENVOLVEDOR.IO – @eduardopiresbr

See Instagram ‘DESENVOLVEDOR.IO’ highlights from Eduardo Pires (@eduardopiresbr)

Microsoft Regional Director

Em Abril eu fui nomeado Diretor Regional Microsoft. É uma premiação super exclusiva, apenas 150 pessoas no mundo possuem esse reconhecimento e a própria Microsoft reconhece estes profissionais como os maiores especialistas do mundo. Wow 🙂

Microsoft MVP 2018

Pelo sexto ano consecutivo eu fui reconhecido como Microsoft MVP.
É sempre uma honra e um privilégio receber esse reconhecimento. Muito grato a todos que me ajudaram a chegar aqui.

https://www.instagram.com/p/BqNKHajhMMz/

Site / Blog

Onde tudo começou, ter um site foi a minha primeira iniciativa de compartilhar meus conteúdos na comunidade técnica. Os resultados tem me surpreendido muito, recebo feedbacks fantásticos, eu mal consigo responder todos em tempo.

Alguns números sobre o site:

  • Acessos: 1.873.344 quase dois milhões de visitas em 2018 \o/
  • Média diária: 3.900
  • Posts: 143
  • Horas de vídeo: 42
  • Comentários: 4.234

O que dizer sobre esse resultado? São tantas coisas, fico muito satisfeito e gostaria de dizer MUITO obrigado a todos que fizeram parte destes números.

Conquistas pessoais

Em 2018 eu foquei um pouco mais em mim, cuidei da saúde, visual, comecei a comer melhor, praticar exercícios e etc. Nunca estive em tão boa forma como nos últimos 10 anos.

Fiz uma ótima viagem pelos EUA onde cruzei de Seattle até São Francisco de carro, conheci Los Angeles, Vegas, Portland, São Francisco e etc. Foi sensacional!

Foi um ano de muita mudança pessoal também, novo relacionamento, amigos, rotina e forma de pensar. Foi um “reboot” completo.

Minha visão de 2019

Em poucas palavras…
2019 PROMETE! Vamos usar toda nossa energia, foco, determinação em conquistar nossas metas e enfrentar desafios de verdade.

Para mim continua sendo um ano de transição, minha meta é finalizar 2019 com um novo modelo de vida onde vou usufruir dele por pelo menos 5 anos. Então vou ter que caprichar.

O que vem pela frente?

Meu ano vai ser mais um ano de muito trabalho. Profissionalmente irei focar em 2 frentes:

  • Transformar o desenvolvedor.io em uma plataforma completa de cursos e uma referência para todos os desenvolvedores.
  • Continuar entregando conteúdo para comunidade através de vídeos, posts, palestras, meetups e etc.

2018 foi um ano inesquecível. Muito obrigado por fazer parte dele.

Desejo a você um excelente 2019! Muito sucesso, estudos, foco e dedicação!
Grande Abraço.

Microservices – Por que você não deveria (ainda) utilizar?

Microservices é uma das sensações do momento, muito se fala sobre este estilo arquitetural e para muitos é a solução de todos os problemas. Entenda sobre os desafios de implementar uma arquitetura de microservices e o que deve ser feito antes para evitar problemas futuros.

Microservices é (mais) um novo termo que está sendo bastante utilizado como definição de arquitetura ideal para aplicações corporativas, o termo inclusive é mais novo do que a própria implementação de fato, sendo que o principal objetivo é desenvolver serviços distribuídos e independentes que compõem uma ou mais aplicações.

“O conteúdo técnico está no vídeo ao final do post, o texto a seguir é apenas uma introdução ao assunto.”

Microservices

Microservices em poucas palavras

Microservices (ou arquitetura de microsserviços) é um estilo arquitetural que propõe uma abordagem de desenvolver uma aplicação através da construção de pequenos serviços, cada um com sua própria responsabilidade (capacidade de negócios) e comunicando-se através de mecanismos “leves”. Geralmente assumem o formato de API’s conversando através de HTTP.

Por serem independentes e pequenos (micro) eles funcionam através de mecanismos de deploy independentes e totalmente automatizados onde há o mínimo de gerenciamento centralizado sobre como são escritos. Sendo assim podem ser escritos em diferentes linguagens e tecnologias e utilizar diferentes tipos de persistência de dados (BD).

Muitas empresas já utilizam com sucesso este estilo arquitetural, por que eu devo evitar começar a desenhar minha arquitetura neste estilo?

Conforme a tecnologia avança ela se torna cada vez mais complexa e requer mais conhecimento técnico de quem vai implementar. No cenário de grande escassez técnica (principalmente no Brasil) percebo que muitos desenvolvedores não estão aptos tecnicamente para entregar uma solução baseada na arquitetura de microservices.

Isso sempre foi um problema, porém a arquitetura de microservices exige muito mais conhecimento do que projetar uma aplicação monolítica tradicional. Sendo assim é altamente recomendável que o arquiteto da futura aplicação em microservices esteja ciente de todos os pré-requisitos e habilidades antes de começar o projeto.

Atuando como consultor eu já atendi dezenas de grandes empresas que falharam na implementação de uma arquitetura de microservices e pior deixaram de entregar a aplicação no prazo ou entregaram com falhas muito graves que comprometeram a disponibilidade e confiabilidade da empresa / serviço.

Como implementar uma arquitetura de microservices de forma responsável e dentro dos pré-requisitos técnicos esperados?

Não existe uma receita para isto. Tudo depende dos skills técnicos da equipe e das plataformas / tecnologias utilizadas na empresa. O que podemos fazer é observar e até mesmo gerar uma lista com pontos cruciais que realmente irão fazer toda a diferença.

Esta lista dos 10 motivos não foi obtida de algum livro / artigo / material. Eu a criei baseada em minhas “cicatrizes” de anos de consultoria, portanto trata-se de minha visão técnica e de consultor, portanto recomendo que assista meu vídeo para compreender melhor sobre estes pré-requisitos/motivos e o por que eles são tão fundamentais.

Espero que vocês aproveitem as dicas e qualquer dúvida estou a disposição.


Vamos continuar a troca de experiências, deixe seu comentário abaixo. Se gostou e concorda com o artigo, compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis.

Implementando o padrão CQRS em aplicações .NET

O padrão CQRS está sendo cada vez mais utilizado para o desenvolvimento e modelagem de aplicações que necessitam de expressividade no domínio, integrações com outras aplicações e um controle mais avançado sobre leitura e escrita de dados.

O conteúdo deste material está em vídeo, pois foi uma palestra online que realizei no Canal .NET e foi gravada ao vivo.

CQRS

O CQRS além de ajudar muito na expressividade do domínio e sobre as intenções de negócio também vai facilitar muito a implementação de uma arquitetura “Event Driven”, que está sendo cada vez mais utilizada em projetos de Microservices e em cenários de muitas integrações.

Caso não conheça o padrão CQRS além deste tutorial eu indico este post que escrevi:

CQRS – O que é? Onde aplicar?

O código fonte de exemplo é do meu projeto open-source chamado Equinox.

Espero que vocês aproveitem o material e qualquer dúvida estou a disposição.


Vamos continuar a troca de experiências, deixe seu comentário abaixo. Se gostou e concorda com o artigo, compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis.

Fui nomeado Microsoft Regional Director

No dia 9 de Abril de 2018 fui nomeado Microsoft Regional Director.
É a premiação mais importante que já recebi e agora faço parte de um time muito enxuto e seleto de profissionais. São apenas cerca de 150 em todo o mundo.

Microsoft Regional Director

O que é ser Microsoft Regional Director?

Microsoft Regional Director é uma premiação. O texto abaixo foi extraído do site oficial rd.microsoft.com

Estabelecido em 1993 o programa conta com 150 dos maiores visionários de tecnologia do mundo, escolhidos especificamente por sua comprovada expertise multiplataforma, liderança comunitária e comprometimento com os resultados do negócio.

Normalmente os Microsoft Regional Directors estão em destaque nos principais eventos do setor, liderando grupos comunitários e iniciativas locais, liderando empresas com foco em tecnologia ou realizando consultorias e implementando os mais recentes avanços em uma corporação multinacional.


Como é receber esta premiação?

Receber uma premiação que me destaca pela própria Microsoft entre 150 dos maiores visionários de tecnologia do mundo é algo surreal. A princípio é difícil me ver merecedor ao ponto de fazer parte deste número extremamente seleto, mas com certeza darei o meu melhor para honrar a premiação que recebi.

Recebi esta premiação devido o meu trabalho com foco de consultor em grandes empresas e meu papel de influenciador tecnológico através de meus treinamentos que já impactaram mais de 9000 alunos e também devido aos eventos dos quais sou organizador ou palestrante.

Para ser um Regional Director além de um grande expertise técnico comprovado é necessário ter uma visão bem generalista sobre tecnologia e como ela pode ser utilizada para gerar negócios. É necessário também ter experiência comprovada como consultor em grandes empresas o que garante que saiba ouvir e entender a necessidade do cliente e ao mesmo tempo entregar soluções técnicas de alta complexidade.

O que muda daqui em diante?

Na minha atuação profissional basicamente nada, vou continuar tocando minhas empresas e contribuindo cada vez mais com a comunidade técnica. Provavelmente devo aumentar meu foco em consultorias especializadas, porém já é algo que faço hoje.


O texto abaixo foi extraído do site oficial rd.microsoft.com

Os Regional Directors trabalham para a Microsoft?

Não, os Regional Directors não são funcionários da Microsoft. Em alguns casos os Diretores Regionais ou suas empresas podem ter contratos para entregar bens ou serviços à Microsoft, mas não são funcionários.

Como os Regional Directors são selecionados pela Microsoft?

Os Regional Directors são escolhidos a dedo pela Microsoft com base em um conjunto rigoroso de avaliações projetadas para selecionar os melhores representantes de desenvolvedores ou profissionais de TI que atendem necessidades estratégicas de tecnologia das empresas com maior impacto no mundo.

Quanto tempo dura o mandato de um Regional Director?

O mandato de um Regional Director é de dois anos.

Como os Regional Directors trabalham com a Microsoft?

Os Regional Directors atuam com capacidade consultiva e são convidados a participar de sessões de feedback estratégico programadas com as equipes de liderança sênior da Microsoft.

Por causa de suas posições de liderança na comunidade, paixão, comprometimento com a tecnologia e excelência nos negócios, os Regional Directors têm um ponto de encontro regular onde podem expressar comentários em tempo real sobre clientes e comunidades diretamente com os engenheiros da Microsoft e com a equipe de liderança sênior, incluindo o presidente da Microsoft Satya Nadella.

Qual é a diferença entre um Regional Director e um MVP?

Muitos dos Regional Directors também possuem o título da premiação MVP, embora a maioria deles esteja encontrando dificuldades para manter as duas credenciais, já que cada uma tem demandas diferentes, o que dificulta a qualificação e a manutenção de ambas. No entanto, as principais diferenças realmente se resumem à natureza consultiva de negócios, experiência em clientes e habilidades de arquiteto de plataforma cruzada possuídas pelos Regional Directors versus o foco técnico profundo que qualifica um MVP.


Gostaria de agradecer especialmente alguns amigos que me ajudaram neste processo tanto no suporte como nas indicações. Sem a ajuda deles não seria possível receber a premiação:

Glauter Jannuzzi, Evilázaro Alves, Jamil Lopes, Claudenir Andrade, Carlos dos Santos e André Carlucci. Muito obrigado mesmo meus amigos!

E agradeço a você leitor deste blog pela confiança e feedback que tem feito desde 2012 um diferencial muito grande em minhas contribuições com a comunidade técnica.

Grande Abraço!

Prevenindo ataques CSRF no ASP.NET Core

Ataques CSRF são bem comuns, o CSRF está listado como a 909° vulnerabilidade mais perigosa já encontrada em um software e é de total responsabilidade do desenvolvedor evitar isto.

Ataque CSRF no ASP.NET Core

CSRF significa Cross-Site Request Forgery (Falsificação de solicitação entre sites).

O CSRF explora a confiança que um website tem do navegador do usuário. Portanto um ataque CSRF é baseado em transmitir um comando não autorizado através de um usuário que o site confia.

Cenário prático de um ataque CSRF

João é administrador de um site de e-commerce e está em seu ambiente de trabalho quando recebe um e-mail que oferece uma promoção imperdível e ao visitar o site da promoção existe um botão para ver mais detalhes, algo assim:

Assim que João clica no botão um post altera a senha de administrador do site e como João é o próprio administrador e estava logado o site executa sua solicitação de imediato. Foi tarde demais para evitar o ataque bem sucedido de um ex-funcionário que estava chateado com a empresa e conhecia a aplicação.

Pode parecer Hollywoodiano demais, mas acontece bastante!

Como evitar o CSRF?

Isto é de total responsabilidade do desenvolvedor, mas o ASP.NET MVC desde suas versões iniciais possui um filtro especial para evitar este tipo de ataque que é o ValidateAntiForgeryToken.

O exemplo abaixo mostra a implementação na Controller e na View:

PS – Apesar de ser permitido não é necessário declarar o AntiForgeryToken na View, pois toda View Razor é protegida automaticamente de CSRF e será gerado um input hidden com o “__RequestVerificationToken” a cada requisição.

Como funciona o ValidateAntiForgeryToken?

O token gerado na View é baseado no usuário logado e na sessão do browser e é submetido via POST para a Controller que deve conter o atributo [ValidateAntiForgeryToken] declarado no método.

Se o servidor recebe um token que não corresponde a identidade do usuário autenticado, a solicitação será rejeitada. O token é exclusivo e imprevisível. O token também pode ser usado para garantir o sequenciamento adequado de uma série de solicitações (página garantia 1 precede a página 2 que precede a página 3).

Se o filtro ValidateAntiForgeryToken estiver declarado o ataque que simulamos no cenário prático não teria sido efetuado com sucesso, pois a aplicação teria rejeitado o POST e retornado um erro 400 (Bad Request).

A OWASP (Open Web Application Security Project) recomenda que todo verbo POST, PUT e DELETE estejam protegidos deste tipo de ataque. (Esta implementação não se aplica no uso de APIs).

Aplicando a proteção contra o CSRF de forma global no ASP.NET Core

É possível que por um deslise o desenvolvedor esqueça de usar o ValidateAntiForgeryToken como atributo em seus métodos, para evitar isto podemos usar a implementação a seguir no Startup.cs e deixar a validação de forma global

Assim não será mais necessário se preocupar com a implementação de proteção do CSRF no código e caso haja necessidade de ignorar a validação de CSRF basta usar o atributo [IgnoreAntiforgeryToken] no método.

O filtro AutoValidateAntiforgeryTokenAttribute utilizado no Startup.cs é inteligente e aplica as validações de CSRF apenas para verbos que modificam o estado de um registro (POST, PUT e DELETE)

PS – Os verbos GET, TRACE etc são idempotentes por natureza e não devem fazer uso de validação de CSRF.

Resumindo

A prevenção de CSRF é apenas uma das preocupações de um desenvolvedor web, existem diversos outros tipos de ataques e eu recomendo que todo desenvolvedor tenha no mínimo o conhecimento deles. Recomendo a leitura do guia OWASP para aplicações .NET que resume os tipos, como funcionam e como se prevenir de cada um deles.

Este é a primeira postagem de uma lista de posts de segurança no ASP.NET Core que eu irei escrever daqui para frente.


Vamos continuar a troca de experiências, deixe seu comentário abaixo. Se gostou e concorda com o artigo, compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis.

Mais um Framework SPA e desta vez é da Microsoft! Conheça o Blazor

Existem diversas opções de frameworks SPA disponíveis e é difícil saber escolher qual é o melhor, agora a Microsoft está investindo em seu próprio framework SPA e ele é bem diferente dos demais. Conheça o Blazor!

Blazor = Browser + Razor

Blazor. (Browser + Razor).
O nome é interessante mas o que o Blazor tem de inovação é mais interessante ainda!

O que é o Blazor?

O Blazor é um framework Web baseado nas tecnologias Web já existentes como HTML e CSS mas usa C# e Razor ao invés de JavaScript.

Como assim? E como o browser vai entender .NET?

O Blazor roda no browser via WebAssembly o que é um de seus maiores diferenciais!

Para quem não conhece o WebAssembly o que tudo indica será o futuro da Web. É como se o Browser funcionasse como uma máquina virtual rodando um código binário (WASM) que é quase tão rápido como código nativo de máquina e possui performance muito superior ao JavaScript.

O WebAssembly está sob a responsabilidade do W3C e já é suportado pela maioria dos browsers modernos.

É possível rodar OpenGL, Banco de dados e etc. Inclusive o engine Unreal 4 já foi portado para WebAssembly assim como o .NET Core está passando pela portabilidade.

Hey Desenvolvedor Web! É melhor começar a ficar de olho nisso hein?

Por que usar .NET no Browser?

O desenvolvimento da Web melhorou de muitas maneiras ao longo dos anos, mas a construção de aplicativos web modernos ainda representa desafios. O uso do .NET no navegador oferece muitas vantagens que podem ajudar a tornar o desenvolvimento web mais fácil e mais produtivo:

  • Estável e consistente: o .NET oferece APIs padrão, ferramentas e infraestrutura de construção em todas as plataformas .NET que são estáveis, ricas em recursos e fáceis de usar.
  • Linguagens inovadoras modernas: linguagens .NET como C# e F# tornam a programação mais fácil e continuam melhorando com novos recursos inovadores na linguagem.
  • Ferramentas líderes da indústria: a família de produtos Visual Studio oferece uma excelente experiência de desenvolvimento .NET no Windows, Linux e MacOS.
  • Rápido e escalável: o .NET possui um longo histórico de desempenho, confiabilidade e segurança para desenvolvimento web no servidor. Usar o .NET como um Stack completo facilita a criação de aplicativos rápidos, confiáveis e seguros.

O que o Blazor oferece?

O Blazor é um projeto experimental, recém anunciado pela Microsoft como parte do Stack do ASP.NET.

O Blazor possui todas as features de um framework SPA moderno:

  • Utiliza o conceito de Component Model
  • Roteamento
  • Layouts
  • Formulários e Validações
  • Dependency Injection nativo
  • Interoperabilidade com JavaScript
  • Atualização automática do browser durante desenvolvimento
  • Renderização server-side
  • Debug em .NET diretamente pela IDE e pelo browser
  • IntelliSense e Tooling
  • Realiza o publishing diminuindo (comprimindo) o tamanho da App

PS – Se o browser não for compatível com WebAssembly o Blazor tem a capacidade de oferecer o asm.js permitindo a mesma experiência até no IE 9 por exemplo.

Futuro da Web?

Enquanto todos os frameworks SPA de mercado são baseados em JavaScript (ou TypeScript) o Blazor entrega um código nativo rodando em performance superior e com muito mais segurança.

Se escrever um código em TypeScript para transpilar JS já é muito mais agradável do que escrever JS puro, imagine poder escrever sua aplicação inteira em .NET?

O JavaScript é atualmente considerado o Assembly da internet, mas na minha visão com a adoção do WebAssembly isto muda totalmente! Até por que qualquer linguagem pode gerar WebAssembly e se beneficiar de todas suas vantagens.

A pergunta que fica:
Qual será o futuro do JavaScript?

Minhas impressões sobre a adoção do Blazor

Pontos positivos:

  • Entrega WebAssembly (já sabemos que é vantagem)
  • Possui todas as features de um framework SPA
  • Permite a reciclagem de conhecimento uma vez que usa .NET com C# e Views em Razor
  • Facilita a curva de aprendizado e de entrega para times que desejam entregar aplicações Web que rodam no client utilizando uma arquitetura baseada em REST.
  • Server-side rendering nativo, ótimo para SEO.
  • DNA! DOT NET Anywhere (.NET em todos os lugares).

Pontos negativos:

  • É super novo e experimental, não sabemos se terá continuidade ou adoção.
  • É baseado em .NET o que restringe desenvolvedores de outras plataformas em aderir (pelo menos rapidamente).
  • Não possui componentes prontos assim como existem para Angular e React (problemas de adotar um framework novo)
  • Não tem suporte da comunidade e 0 documentação.
  • Não funciona 100% no Visual Studio ou no Code (falta tooling).

Notem que a maioria dos pontos negativos é devido ao Blazor ser extremamente novo, com o tempo e o sucesso na adoção (e bastante investimento da Microsoft) isto tende a mudar.

O único ponto imutável é que o Blazor é baseado em .NET. Enquanto um desenvolvedor Angular pode mudar para React ou Vue sem ter que aprender uma nova linguagem o mesmo não acontecerá com o Blazor, o que pode ser um limitador para desenvolvedores de outras plataformas.

De outro lado desenvolvedores WebForms, MVC, Xamarin e etc poderão se beneficiar imediatamente e começar a entregar aplicações SPA com uma performance e segurança superior.

Isto é sério mesmo?

Entregar o .NET Core por completo pela Web com cerca de 300 KB?
Até mesmo o novo Angular pesa um pouco mais que isso!

Para saber mais

Assista essa demo de TODO List com Blazor (é muito interessante)

O projeto é OpenSource (Microsoft <3)
https://github.com/aspnet/Blazor/

E para finalizar! O que acham do Blazor e WebAssembly?


Vamos continuar a troca de experiências, deixe seu comentário abaixo. Se gostou e concorda com o artigo, compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis.