<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>wellingtonjhn.com</title>
    <link>https://wellingtonjhn.com/</link>
    <description>Recent content on wellingtonjhn.com</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-US</language>
    <copyright>This work is licensed under MIT License.</copyright>
    <lastBuildDate>Sun, 15 Sep 2019 00:00:00 +0000</lastBuildDate>
    
	<atom:link href="https://wellingtonjhn.com/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>CQS  -  Command Query Separation</title>
      <link>https://wellingtonjhn.com/posts/cqs---command-query-separation/</link>
      <pubDate>Sun, 15 Sep 2019 00:00:00 +0000</pubDate>
      
      <guid>https://wellingtonjhn.com/posts/cqs---command-query-separation/</guid>
      <description>O CQS (Command Query Separation) é um pattern introduzido por Bertrand Meyer no livro Object Oriented Software Construction, com a primeira edição publicada em 1988, e a segunda, revisada e expandida em 1997.
A idéia principal é que os métodos de uma aplicação podem ser comandos (commands) ou consultas (queries), mas nunca ambos.
Temos então:
 Commands: métodos que alteram estado (mudam valores) sem retornar nenhum valor, e causam efeitos colaterais no sistema.</description>
    </item>
    
    <item>
      <title>Padronização de Respostas de Erro em APIs com Problem Details</title>
      <link>https://wellingtonjhn.com/posts/padroniza%C3%A7%C3%A3o-de-respostas-de-erro-em-apis-com-problem-details/</link>
      <pubDate>Sat, 19 Jan 2019 00:00:00 +0000</pubDate>
      
      <guid>https://wellingtonjhn.com/posts/padroniza%C3%A7%C3%A3o-de-respostas-de-erro-em-apis-com-problem-details/</guid>
      <description>Como sabemos existem centenas de milhares de APIs no mundo, e a cada dia outras milhares surgem. Cada uma delas tem o seu próprio padrão de mensagens de erro, não existindo um consenso comum.
Você pode conferir um pouco desse problema verificando as APIs do Facebook, Google e Twitter por exemplo. Cada uma delas possui seu próprio formato para mensagens de erro.
 Google Standard Error Response Facebook Graph API Error Response Twitter API Error Response  Diante disso foi criada a RFC 7807, que é uma especificação que visa padronizar os formatos de mensagens de erro em APIs HTTP, para assim evitar que novos formatos sejam criados.</description>
    </item>
    
    <item>
      <title>Não lance Exceptions em seu Domínio… Use Notifications!</title>
      <link>https://wellingtonjhn.com/posts/n%C3%A3o-lance-exceptions-em-seu-dom%C3%ADnio-use-notifications/</link>
      <pubDate>Sun, 25 Nov 2018 00:00:00 +0000</pubDate>
      
      <guid>https://wellingtonjhn.com/posts/n%C3%A3o-lance-exceptions-em-seu-dom%C3%ADnio-use-notifications/</guid>
      <description>É muito comum encontrar nos sistemas corporativos o lançamento de Exceptions ao realizar validações de regras de negócio ou entrada de dados de formulários, afinal de contas é necessário informar ao usuário que algo deu errado.
 Porém, o que nós geralmente esquecemos é que Exceptions são inesperadas e elas indicam um erro, uma exceção ao funcionamento normal do sistema, algo que não era para ter acontecido, mas aconteceu.</description>
    </item>
    
    <item>
      <title>Tratamento Global de Exceptions no ASP.Net Core</title>
      <link>https://wellingtonjhn.com/posts/tratamento-global-de-exceptions-no-asp.net-core/</link>
      <pubDate>Mon, 05 Nov 2018 00:00:00 +0000</pubDate>
      
      <guid>https://wellingtonjhn.com/posts/tratamento-global-de-exceptions-no-asp.net-core/</guid>
      <description>Desde as primeiras versões do C# temos à nossa disposição o famoso bloco try…catch, onde podemos capturar exceções e tratá-las da melhor forma possível, seja gravando um log, adicionando uma mensagem amigável para o usuário, etc. Porém, muitas vezes não conseguimos prever todos os possíveis erros que possam acontecer e muitas exceções acabam “explodindo” na tela para o usuário, ou pior, causam a queda de nossos sistemas e até mesmo prejuízos financeiros para nossos clientes.</description>
    </item>
    
    <item>
      <title>Validando Objetos de Configuração no .Net Core</title>
      <link>https://wellingtonjhn.com/posts/validando-objetos-de-configura%C3%A7%C3%A3o-no-.net-core/</link>
      <pubDate>Sat, 08 Sep 2018 00:00:00 +0000</pubDate>
      
      <guid>https://wellingtonjhn.com/posts/validando-objetos-de-configura%C3%A7%C3%A3o-no-.net-core/</guid>
      <description>No artigo anterior eu falei sobre alguns conceitos básicos do modelo de configuração do .Net Core, e um dos itens abordados é a possibilidade de podermos usar objetos POCO para representar grupos de configuração relacionadas entre si usando Options Pattern.
Nesse artigo irei mostrar como podemos validar esses objetos de configuração de forma a garantir que eles foram instanciados corretamente, uma vez que estamos totalmente suscetíveis a erros no momento em que definimos as configurações de nossa aplicação, e podemos deixar algum valor importante em branco por exemplo.</description>
    </item>
    
    <item>
      <title>Configurando suas aplicações .Net Core</title>
      <link>https://wellingtonjhn.com/posts/configurando-suas-aplica%C3%A7%C3%B5es-.net-core/</link>
      <pubDate>Mon, 30 Jul 2018 00:00:00 +0000</pubDate>
      
      <guid>https://wellingtonjhn.com/posts/configurando-suas-aplica%C3%A7%C3%B5es-.net-core/</guid>
      <description>Antigamente tínhamos os arquivos Web.Config e App.Config em nossas aplicações .Net Framework que na verdade eram arquivos XML onde podíamos colocar as configurações de nossas aplicações, e em conjunto à eles usávamos a classe ConfigurationManager para acessá-los. Muitas vezes esses arquivos se tornavam verdadeiros monstros e sua manutenção traumatizante para muitos desenvolvedores.
Com o lançamento do .Net Core e ASP.Net Core há alguns anos, ganhamos um novo mecanismo de configuração ainda mais poderoso, flexível e simples.</description>
    </item>
    
    <item>
      <title>Autenticação em APIs ASP.Net Core com JWT - Refresh Token</title>
      <link>https://wellingtonjhn.com/posts/autentica%C3%A7%C3%A3o-em-apis-asp.net-core-com-jwt---refresh-token/</link>
      <pubDate>Tue, 17 Jul 2018 00:00:00 +0000</pubDate>
      
      <guid>https://wellingtonjhn.com/posts/autentica%C3%A7%C3%A3o-em-apis-asp.net-core-com-jwt---refresh-token/</guid>
      <description>Quando trabalhamos com autenticação baseada em tokens JWT temos que considerar que ele tem um tempo de expiração que irá invalidá-lo em determinado momento. Em alguns cenários pode ser interessante obter um novo token de acesso sem precisar forçar o usuário a fazer um novo login informando seu usuário e senha. Isso é muito comum quando trabalhamos com aplicativos mobile.
 Para esse artigo usei o mesmo exemplo de código de um artigo anterior onde mostro como implementar uma API de Autenticação simples com JWT.</description>
    </item>
    
    <item>
      <title>Documentação de APIs com Swagger no ASP.Net Core</title>
      <link>https://wellingtonjhn.com/posts/documenta%C3%A7%C3%A3o-de-apis-com-swagger-no-asp.net-core/</link>
      <pubDate>Sun, 10 Jun 2018 00:00:00 +0000</pubDate>
      
      <guid>https://wellingtonjhn.com/posts/documenta%C3%A7%C3%A3o-de-apis-com-swagger-no-asp.net-core/</guid>
      <description>Não basta apenas desenvolver nossas aplicações e largar na mão dos times que farão uso delas. Uma boa documentação é um dos quesitos chave para o sucesso de todo sistema hoje em dia, ainda mais em um mundo de APIs que vivemos hoje, onde existem cada vez mais integrações entre aplicações e serviços.
Imagina você ter que entrar em contato com o desenvolvedor de determinada API para saber quais endpoints você precisa usar, e quais são os parâmetros necessários para a correta integração com seu sistema.</description>
    </item>
    
    <item>
      <title>Autorização em APIs ASP.Net Core</title>
      <link>https://wellingtonjhn.com/posts/autoriza%C3%A7%C3%A3o-em-apis-asp.net-core/</link>
      <pubDate>Thu, 31 May 2018 00:00:00 +0000</pubDate>
      
      <guid>https://wellingtonjhn.com/posts/autoriza%C3%A7%C3%A3o-em-apis-asp.net-core/</guid>
      <description>Em um artigo anterior eu falei sobre a criação de uma API de Autenticação utilizando ASP.Net Core. Hoje quero falar um pouco sobre como podemos fazer a Autorização de nossos usuários dentro das APIs.
Sendo que no artigo citado acima eu fiz uma breve introdução sobre os conceitos de Autenticação e Autorização, então, se você não viu corre lá e depois volte aqui.
Os recursos de autorização descritos neste artigo foram implementados a titulo de demonstração nesse projeto que está no meu Github.</description>
    </item>
    
    <item>
      <title>Obtendo o Usuário Logado em APIs ASP.Net Core</title>
      <link>https://wellingtonjhn.com/posts/obtendo-o-usu%C3%A1rio-logado-em-apis-asp.net-core/</link>
      <pubDate>Sat, 12 May 2018 00:00:00 +0000</pubDate>
      
      <guid>https://wellingtonjhn.com/posts/obtendo-o-usu%C3%A1rio-logado-em-apis-asp.net-core/</guid>
      <description>No artigo anterior eu mostrei como criar uma API de autenticação em ASP.Net Core com JWT. Hoje iremos ver como podemos obter o usuário autenticado, extraindo os dados do token de uma forma muito simples.
Para isso o ASP.Net Core oferece uma biblioteca de abstrações HTTP (pacote nuget Microsoft.AspNetCore.Http.Abstractions) que contém a interface IHttpContextAccessor.
A classe HttpContextAccessor implementa tal interface, e possui uma propriedade onde podemos obter o HttpContext da requisição e com ele a identidade do usuário logado.</description>
    </item>
    
    <item>
      <title>Autenticação em APIs ASP.Net Core com JWT</title>
      <link>https://wellingtonjhn.com/posts/autentica%C3%A7%C3%A3o-em-apis-asp.net-core-com-jwt/</link>
      <pubDate>Wed, 02 May 2018 00:00:00 +0000</pubDate>
      
      <guid>https://wellingtonjhn.com/posts/autentica%C3%A7%C3%A3o-em-apis-asp.net-core-com-jwt/</guid>
      <description>A segurança de aplicações sempre foi, ou deveria ser, uma das principais preocupações dos times de desenvolvimento, e nos últimos anos a autenticação de APIs vem sendo bastante discutida nas comunidades técnicas em todo o mundo.
Existem diversas maneiras de resolver a autenticação em APIs, e uma delas é fazendo uso de tokens de acesso, sendo o JWT (Json Web Token) um dos padrões de tokens de acesso mais famosos e seguros da atualidade.</description>
    </item>
    
    <item>
      <title>Contato</title>
      <link>https://wellingtonjhn.com/contact/</link>
      <pubDate>Thu, 12 Apr 2018 00:00:00 +0000</pubDate>
      
      <guid>https://wellingtonjhn.com/contact/</guid>
      <description>Caso você tenha alguma crítica, sugestão, ou apenas queira bater um papo, fique à vontade para entrar em contato. Irei responder assim que possível.
EnviarObrigado! Seu e-mail foi enviado. </description>
    </item>
    
    <item>
      <title>Fail-fast Validations com Pipeline Behavior no MediatR e ASP.Net Core</title>
      <link>https://wellingtonjhn.com/posts/fail-fast-validations-com-pipeline-behavior-no-mediatr-e-asp.net-core/</link>
      <pubDate>Mon, 09 Apr 2018 00:00:00 +0000</pubDate>
      
      <guid>https://wellingtonjhn.com/posts/fail-fast-validations-com-pipeline-behavior-no-mediatr-e-asp.net-core/</guid>
      <description>Sabemos que o MediatR simplifica muito o design de nossas aplicações tornando nosso código mais simples e com baixo acoplamento, conforme eu mostrei no artigo anterior. Se você não viu corre lá e depois volte aqui.
Um dos recursos mais legais dele é a possibilidade de executarmos determinadas ações antes ou depois de um Handler ser disparado. Esse recurso leva o nome de Pipeline Behavior.
Você pode usar o Pipeline Behavior para, por exemplo, validar os parâmetros de entrada dos Requests, autorizar o acesso à determinado Handler, gravar log dos Requests, etc.</description>
    </item>
    
    <item>
      <title>MediatR com ASP.Net Core</title>
      <link>https://wellingtonjhn.com/posts/mediatr-com-asp.net-core/</link>
      <pubDate>Fri, 30 Mar 2018 00:00:00 +0000</pubDate>
      
      <guid>https://wellingtonjhn.com/posts/mediatr-com-asp.net-core/</guid>
      <description>O Mediator é um padrão de projeto Comportamental criado pelo GoF, que nos ajuda a garantir um baixo acoplamento entre os objetos de nossa aplicação. Ele permite que um objeto se comunique com outros sem saber suas estruturas. Para isso devemos definir um ponto central que irá encapsular como os objetos irão se comunicar uns com os outros.
Neste artigo iremos ver como podemos criar uma API ASP.Net Core que faz uso desse padrão de projeto usando a biblioteca MediatR.</description>
    </item>
    
    <item>
      <title>Compressão de Respostas em APIs ASP.Net Core</title>
      <link>https://wellingtonjhn.com/posts/compress%C3%A3o-de-respostas-em-apis-asp.net-core/</link>
      <pubDate>Sat, 17 Mar 2018 00:00:00 +0000</pubDate>
      
      <guid>https://wellingtonjhn.com/posts/compress%C3%A3o-de-respostas-em-apis-asp.net-core/</guid>
      <description>Quando estamos desenvolvendo nossas APIs é muito importante nos preocuparmos com o tráfego de mensagens que ela irá gerar, pois largura de banda é um recurso limitado e não podemos esperar que nossos clientes irão poder contar com conexões de banda larga via fibra ótica à todo momento, ou ainda, conexões 4G ultra velozes sem limites de dados. Infelizmente essa não é a nossa realidade ainda&amp;hellip; =/
O que podemos fazer é reduzir o tamanho das respostas em nossas APIs, e isso tem um impacto muito grande tanto financeiro, quanto de performance.</description>
    </item>
    
    <item>
      <title>Entendendo tokens JWT</title>
      <link>https://wellingtonjhn.com/posts/entendendo-tokens-jwt/</link>
      <pubDate>Mon, 26 Feb 2018 00:00:00 +0000</pubDate>
      
      <guid>https://wellingtonjhn.com/posts/entendendo-tokens-jwt/</guid>
      <description>O JWT é um padrão (RFC-7519) de mercado que define como transmitir e armazenar objetos JSON de forma compacta e segura entre diferentes aplicações. Os dados nele contidos podem ser validados a qualquer momento pois o token é assinado digitalmente.
Ele é formado por três seções: Header, Payload e Signature.
Header O Header é um objeto JSON que define informações sobre o tipo do token (typ), nesse caso JWT, e o algorítmo de criptografia usado em sua assinatura (alg), normalmente HMAC SHA256 ou RSA.</description>
    </item>
    
    <item>
      <title>Badges</title>
      <link>https://wellingtonjhn.com/posts/badges/</link>
      <pubDate>Fri, 05 Jan 2018 00:00:00 +0000</pubDate>
      
      <guid>https://wellingtonjhn.com/posts/badges/</guid>
      <description>No artigo anterior vimos como configurar o Travis e AppVeyor para fazer todo o processo de build e deploy de um componente Nuget escrito em .Net Core. Agora veremos como podemos configurar “badges” em nosso repositório para exibir o status de build do nosso projeto.
Para isso vamos usar o shields.io pois ele permite que façamos algumas customizações escolhendo por exemplo um label, formato, tamanho, etc.
Acessando o shields.io, veremos uma lista enorme de badges que podemos usar, escolha a que melhor se adequa ao que você quer exibir e clique para editar.</description>
    </item>
    
    <item>
      <title>CI-CD com Travis e AppVeyor usando Cake e .Net Core</title>
      <link>https://wellingtonjhn.com/posts/ci-cd-com-travis-e-appveyor-usando-cake-e-.net-core/</link>
      <pubDate>Thu, 04 Jan 2018 00:00:00 +0000</pubDate>
      
      <guid>https://wellingtonjhn.com/posts/ci-cd-com-travis-e-appveyor-usando-cake-e-.net-core/</guid>
      <description>No artigo anterior usamos o Cake para fazer build, executar testes, gerar pacotes e deploy no repositorio oficial do Nuget através de um script de tarefas. Se você não viu corre lá e depois volte aqui.
Hoje iremos usar esse script em conjunto com duas ferramentas de CI/CD muito populares, o Travis e AppVeyor, pois não queremos ficar executando esse script de forma manual em nosso próprio computador.
 Ambas as ferramentas são gratuitas para projetos open source e oferecem planos pagos para projetos privados.</description>
    </item>
    
    <item>
      <title>Automatizando Tarefas de build, teste e deploy de pacotes Nuget com Cake e .Net Core</title>
      <link>https://wellingtonjhn.com/posts/automatizando-tarefas-de-build-teste-e-deploy-de-pacotes-nuget-com-cake-e-.net-core/</link>
      <pubDate>Wed, 22 Nov 2017 00:00:00 +0000</pubDate>
      
      <guid>https://wellingtonjhn.com/posts/automatizando-tarefas-de-build-teste-e-deploy-de-pacotes-nuget-com-cake-e-.net-core/</guid>
      <description>É muito chato ter que fazer o build, rodar testes, executar a análise de qualidade do código, entre outras tarefas, de forma manual em nossas aplicações, e o assunto se complica ainda mais quando temos que executar essas mesmas tarefas em ferramentas de CI como é o caso do VSTS, GoCD, Jenkins, entre outros.
Já trabalhei com automação de pipelines de CI/CD com scripts PowerShell e Rake, e além dessas, ainda existem diversas outras ferramentas de automatização de tarefas como o Gulp, Fake, Psake, etc, e para nossa felicidade o Cake.</description>
    </item>
    
    <item>
      <title>Sobre</title>
      <link>https://wellingtonjhn.com/about/</link>
      <pubDate>Tue, 14 Apr 2015 22:17:00 +0000</pubDate>
      
      <guid>https://wellingtonjhn.com/about/</guid>
      <description>Sobre o blog Bem-vindo ao meu blog, ele foi criado para que eu possa compartilhar minha experiência e aprendizados nas tecnologias que eu uso em meu dia a dia, de forma que eu também possa ajudar outros desenvolvedores a alcançar níveis mais altos de qualidade em seu trabalho.
Alguns artigos desse blog também foram publicados em outros portais especializados como iMasters e Tableless.
Também possuo uma versão dos meus artigos no Medium, onde tenho uma boa audiência.</description>
    </item>
    
  </channel>
</rss>