Autor: magoolation

Fala galera!

É muito comum que durante nosso desenvolvimeno tenhamos de fazer conversão de tipos.

Seja converter de uma string que veio do input de usuário para tipos como int, float ou decimal, seja convertendo de um tipo de dados que veio de uma API interna ou externa.

Para a mioria destas conversõs podemos utilizar a classe Convert e seus métodos específicos:

ToInt32, ToDouble, ToLong, etc.

Mas há conversões ainda mais avançadas e que pouco utilizamos, apesar de serem bem úteis.

Temos o Convert.ToBase64String e Convert.FromBase64String que faz a vpnersão de um objeto para uma presentação em Base64 muito útil para ser enviada através da Web e outros protocolos de comunicaÇão baseados em texto onde caracteres especiais podem ser rejeitados.

Mas o método mais poderoso é o ChangeType. Ele recebe dois parametros onde o primeiro é o objeto a ser convertido e o segundo o tipo para o qual ele deve ser convertido.

Ainda não me deparei com o código fonte deste método, mas ele tem sido particularmente útil em desenvolvimento Xamarin na conversão em APIs que retornam java.lang.object.

Em breve publico aqui um exemplo mais comncreto, mas conhecer bem o framework ajuda demais a resolver problemas que parecem complexos com algo que já está lá pronto esperando pra ser usado.

Até amanhã!

Fala galera!

Para quem escreve muitos códigos paralelos em .NET estamos devidamente educados a utilizar Task e async await.

Mas quando nos deparamos com delegates e event handlers que são void cometemos o crime de usar async void.

Isto gera alguns problemas pois o método não pode ser devidamente aguardado, afinal ele não tem uma Task que poderá ser monitorada, e o código é executado de forma paralela mas sem nenuma obseva’~ao.

Isto nos leva a unhandled exceptions dentro deste processo, causando erros estranhos ou até mesmo a finalização por completo da nossa áplicação.

E isto mesmo s colocando blocos try catch dentro do método void.

Como então devemos tratar estes casos?

Temos duas oluções:

A primeira é usamos este método void apenas para dar um await em um oputro método, este sim retornando uma Task e com seu devido código de tratamento de erro.

O segundo, e no qual achei a solução mais interessante é a de ~criação de um método de extensão para Task que faz o tratamento da exceção.

Deixo aqui o repositório como a minha tentativa de implementação, e como sempre

conto com os comentários de vocês.

https://github.com/magoolation/no-async-void
Até amanhã!

Fala galera!

Bem sumido daqui. Em breve irei escrever sobre o quanto está sendo dificil manter a rotina de escrever diariamente, das minhas tentativas e quais meus planos para conseguir atingir a meta, que a esta hora já se tornou ter 365 posts até o fim do ano e não mais um post postado diariamente.

Enfim indo direto ao ponto do post de hoje as vezes nicializamos um repositório git localmente e logo antes de enviarmos para o github criamos o repositório remoto.

Como fazemos então para sincronizar os dois?

No repositório local dispare o comando:

git fetch origin master

Faça suas alterações e conclua com um git push -u origin master

Pela segunda vez fiquei preso nesta situação hoje, e espero que como eu vocêambém tenha pensado que é simples demais para gente tr perdido temo com isto.
Até amanhã!

Fala galera!

Desculpem postergar tanto a postagem deste código mas as coisas estiveram bem corridas pelo lado de cá, tanto que postei anteriormente uma solução importante com Polly que estava tirando meu sono.

O código deste experimento está em: https://github.com/magoolation/Async-x-Reactive.

Agradeceria comentários e sugestões de melhoria. Comecei a ler online o livro Rx.NET in Action, onde irei aprender um pouco mais sobre RX e com certeza revisitarei diversas vezes estes repositórios.

Não me prolongando muito tentei comparar os seguintes cenários:

Chamadas async consecutivas;

Chamadas async concorrentes;

Chamadas reativas;

Conversão de chamadas reativas em async;

Os resultados foram interessantes. Logicamente chamadas concorrentes são mais rápidas, mas nem sempre as chamadas reativas os ão, apesar de serem mais legívies, e no caso de chamadas Http serem mais rápidas.

Mas como disse é um experimento a ser melhorado.

Até amanhã!

Fala galera!

Dando uma pausa nos posts sobre programação reativa, que voltarei na próxima postagem, tive de fazer uma correção em um código meu pois minha implementaÇão com Polly não estava adequada.

Bom para quem não conhece o padrão pense no Circuit Breaker como os dijuntores de sua humilde residencia.

Quando o circuito está fechado a energia passa tranquilamente. Este é o modo de operação normal.

Quando há algum problema em seu sistema elétrico, melhor dizendo no da sua caa, os circuitos se abrem e a energia para de passar.

Vocêdoe verificar o problema, fechar apenas um circuito, verificar que está ok e fechar os demais, ou constatar que o problema persiste e mante-los abertos.

A mesma coisa acontece com o padrão Circuit Breaker. Vocêmonitora a ocorrencia de erros, após um limite vocêbre o circuito por um tempo de terminado e após este tempo é feita uma nov nova tentativa, e caso seja positiva o circuito é fechado novamente.

Em resumo monitoramos um número de ocorrencias e caso o circuito abre retornamos uma excessão imediatamente não fazendo o cliente aguardar toda verificação de que o serviço consultado caiu.

Pooly é uma bblioteca de resiliencia que permite criar diversos tipos de política como Retry, Circuit Breaker, Throtling entre outras.

Seu uso é muito simples e demonstro isto no repositório: https://github.com/magoolation/Polly-CircuitBreaker

O código é simples e auto explicativo por isto nÃo me prolongarei aqui, mas caso precisem de algum auxílio ou tenha sugestão de melhorias é só entrar em contato.

PS: Para que o circuit breaker funcione adequeadamente é necessário que tenhamos uma instancia única da política e que façamos com que ela trate apenas as ecessões e casos que estejamos interessados, e esta foi minha falha na outra implementação.

Até amanhã!

Fala galera!

Antes de compartilhar meu experimento achei válido compartilhar algumas coisas com você.

Em primeiro lugar a documentação atualizada. Aqui é a classe Observable que é um ponto de partida para o estudo da programação reativa: https://docs.microsoft.com/en-us/previous-versions/dotnet/reactive-extensions/hh244252%28v%3dvs.103%29.

Lembrando que o padrão Observer é um design pattern já conhecido e as Reactive Extensions, implementadas praticamente em qualquer linguagem moderna hoje, é uma abstração sobre este pattern d forma a tronar a criação, composição e consumo de fluxo de dados ainda mais fácil e elegante.

Neste padrão temos dois atores, os Observables que são os fluxos de dados em si e fornecem as informções quedevem ser processadas, e os Observers que reagem aos fluxos de dados e executam as regras de negócio.

Im Observer implementa um método OnNext que ;é chamado para cada elemento do Observable. Caso ocorra um erro é chamado o método OnError passando-se a excessão disparada. Já ao terminar o fluxo é chamado o OnCompleted.

É realmente muito interessante o quanto o padrão, tão antigo e simples, trouxe para nós uma facilidade tão grande nos dias de hoj.

Bons estudos.

Até amanhã!