Categoria: Arquivo técnico

Este artigo foi publicado em 2019. Ferramentas e versões citadas podem ter mudado desde então; a reflexão permanece.

Fala galera! Depois de muito tempo tento voltar aqui. Em breve publico mais novidades sobre minha trajetória profissional mas hoje venho com algo que me surpreendeu positivamente. As vezes precisamos fazer algumas provas de conceito, provar que algo funciona de determinada forma dentro da linguagem, experimentar alguma nova feature do compilador mas nÃo temos nem tempo, e as vezes nem abiente para fazer estes testes. O correto agora é dizer que não tinhamos. A algum tempo temos o site https://try.dot.net onde podemos escrever e testar nossos códigios em um ambiente totalmente online. A impressão que me passa é que este site é praticamente o editor C# do Visual Studio Code embarcado em um site, e o resultado é realmente muito rápido. Espero que ajudem nos estudos de C#! Até a próxima!

Este artigo foi publicado em 2019. Ferramentas e versões citadas podem ter mudado desde então; a reflexão permanece.

Fala galera! O título parece familiar mas não estou falando do Xamarin Summit Brasil, o maior evento de Xamarin da América Latina, o qual em breve trarei novidades. Estou falando do Xamarin Developers Summit organizado pelo Dan Siegel e que acontecerá dias 11 e 12 de julho no Texas, USA. Na útima sexta-feira recebi a confirmaçao e irei apresentar pela primeira vez uma palestra totalmente no idioma da rainha e de quebra falar sobre acessibilidade. Estou muito feliz com mais este reconhecimento e espero de verdade que eu possa compartilhar uma mensagem de que acessibilidad é sim algo fundamental em nossos aplicativos e que em Xamarin.Forms é muito fácil de se implementar. Até a próxima!

Este artigo foi publicado em 2019. Ferramentas e versões citadas podem ter mudado desde então; a reflexão permanece.

Fala galera! Tivemos no grupo do WhatsApp da lista de cegos programadores uma discussão bem interessante sobre o uso do WSL (Windows Subsystem for Linux), docker e máquinas virtuais. É sábido de muitas pessoas com deficiencia visual que necessitam utilizar virtualização que nem sempre o desempenho dos leitores de tela nas máquinas emuladas é satisfatório, principalmente quando temos o Windows como sistema hospedeiro. Outro grande problema é a forma como nos comunicamos com softwares que rodam nestas máquinas, tais como servidores, infraestrutura e etc. Apesar de passar boa parte do meu dia utilizando Parallels e Windows 10 dentro de um OSX, meu mundo dos sonhos seria ter uma máquina Windows full time, utilizando todo poder de fogo mas mesmo assim podendo desenvolver e depurar aplicativos iOS. O serne da questão é que quando utilizamos docker reduzimos praticamente a zero a necessidade de ambientes Linux para quem está acostumado a ambiente Windows. Desde que se saiba o que que se está fazendo podemos empacotar e utilizar diversos aplicações Linux dentro de containers de forma totalmente transparente. Dando um exemplo, tenho o pandoc, um convertedor universal de formatos de textos, gerador de PDF, ePub e outros, rodando no docker sem a necessidade de investir um minuto em infraestrutura para ter um ambiente rodando. Logicamente o WSL nos trouxe outras possibilidades como o desenvolvimento inclusive de aplicações C++ totalmente em uma máquina Windows mas com target em distribuições Linux. Para projetos iniciados em ambiente Linux, com diversos scripts shell a migração também se torna transparente. Mas como eu disse, cada variável a mais que adicionamos em nossa infra, mais um ponto de atenção adicionamos a nossa lista de verificações quando estamos fazendo um troubleshooting. De forma bem reduzida diria que um ambiente saudável hoje tem Windows 10, docker e no máximo WSL. Qualquer ingrediente am ais é arriscado para a sua receita dar certo. O que você tem usado? Até a próxima!

Este artigo foi publicado em 2019. Ferramentas e versões citadas podem ter mudado desde então; a reflexão permanece.

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ã!

Este artigo foi publicado em 2019. Ferramentas e versões citadas podem ter mudado desde então; a reflexão permanece.

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ã!

Este artigo foi publicado em 2019. Ferramentas e versões citadas podem ter mudado desde então; a reflexão permanece.

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ã!

Este artigo foi publicado em 2019. Ferramentas e versões citadas podem ter mudado desde então; a reflexão permanece.

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ã!

Este artigo foi publicado em 2019. Ferramentas e versões citadas podem ter mudado desde então; a reflexão permanece.

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ã!

Este artigo foi publicado em 2019. Ferramentas e versões citadas podem ter mudado desde então; a reflexão permanece.

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ã!

Este artigo foi publicado em 2019. Ferramentas e versões citadas podem ter mudado desde então; a reflexão permanece.

Fala galera! Agora com o gt bem configurado, como disse no post anterior, pude publicar um experimento interessante que fiz para poder me aperfeiçoar no uso de programação concorrente em .NET. Desde que ganhamos o async await a programação de serviços que necessitavam de paralelismo, como hcamadas a APIs, I/O e comunicação em rede em geral s tornou muito fácil apesar de muita gente, eu inclusivo, ter demorado para entendr o seu real uso. Mas algo que se tornoucomum em meu dia desde que entrei no projeto atual foi o uso de programação reativa (Reactive Programming) com o uso da System.Reactive, seus tipos, e todo conjunto de regras que rodeiam os Observables e Observers. Para quem não conhece este paradigma ao invés d programarmos de forma imperativa chamando algo e aguardando e recebendo imediatamente o que solicitamos, seja lá o que imediatamente signifique entre milesegundos e minutos, na programação reativa trabalhamos com fluxos de dados que nos notificam esó então atuamos. Por exemplo podemos observar um evento de tap em um botão, neste momento solicitar dados em uma API, e só quando recebermos estes dados atualizarmos a interface do usuário. Como reatividade e paralelismo andam juntos com isto liberamos a thread principal para que nosso aplicativo não fique travado. Temos centenas de operadores que podem ser aplicados para filtrar, combinar, transformar e extrair mais informações destes fluxos e isto abre uma gama ainda maior de possibilidades. Mas novamente conhecer bem estes conceitos é o que faz vocêfazer um bom uso e ter real controle da sua aplicação. Na próxima postagem irei compartilhar o repositório e descrever quais foram minhas experiencias. Até amanhã!