No último um ano e meio tenho participado de um projeto do qual tenho muito orgulho e no qual vejo muito futuro. Este projeto é o Tucano Games, onde sou Microsoft MVP Mentor. Junto com os professores Dr. Luciano Araújo e Dr. Carlos Monteiro temos tido a excelente oportunidade de usar nossos conhecimentos para construir um projeto que já tem ajudado muitas crianças e famílias. E, no último dia 28 de Abril, tivemos a felicidade de ganhar o ImagineCup Brasil na Categoria Cidadania Mundial.
Tive a felicidade de participar pela terceira vez do Visual Studio Summit, evento sobre tecnologias Microsoft.
Nesta última participação palestrei sobre Profiling de Aplicações .NET.
Aqui existe um link para o evento Visual Studio Summit 2014.
Mais detalhes sobre o uso de profiling podem ser encontrados neste link: Profiling de Aplicações .NET
Mesmo com o melhor desempenho e os melhores profissionais, problemas relacionados a performance podem surgir. Fazer com que uma aplicação execute de forma performática pode parecer uma tarefa fácil, mas isso pode se tornar uma arte oculta.
Ferramentas de profiling monitoram a execução de uma aplicação com o objetivo de medir os recursos computacionais (tempo, processamento e memória) gastos por um método por toda a sua execução. Seu objetivo é identificar pontos na aplicação que causem problemas em sua execução.
O profiling de aplicações .NET é mais complexo do que aplicações em código de máquina, pois o .NET faz uso de recursos como Application Domains, Garbage Collection, Exception Handling e Just-in-Time Compilation, recursos que tornam o processo de captura dos métodos em execução mais complexo.
Nos anos 80 era comum o fato de uma aplicação conter um único processo que executasse um único fluxo de execução. Aplicativos mais complexos, que continham concorrência entre atividades internas, exigiam uma mudança neste comportamento e foram base para uma revolução no modo como os sistemas operacionais funcionavam.
Nesta época percebeu-se que era preciso aprimorar o funcionamento dos processos para que eles fossem associados a múltiplas atividades concorrentes.
Hoje os processos consistem de um ambiente de execução que gerencia diferentes recursos. Dentre estes recursos encontramos as threads, que correspondem a uma abstração do sistema operacional para uma atividade a ser executada.
Métodos assíncronos são convenientes, pois executam trabalhos de longa duração sem bloquear a thread chamadora, isto é, a thread que originou a execução do método assíncrono pode prosseguir a sua execução sem que seja necessário esperar pelo término do método em execução.
Operações tradicionais de criação de métodos assíncronos podem ser complicadas de serem implementadas, sendo difíceis de serem escritas, debugadas e mantidas. Métodos async correm contra estas complicações e facilitam todo o processo de manutenção e criação de métodos assíncronos devido a sua sintaxe enxuta.
A palavra-chave async posicionada antes da definição do tipo de dados de um método (ou lambda expression, ou método anônimo) indica que o mesmo é assíncrono.
Comumente recebo e-mails sobre: “Qual tecnologia de acesso a dados devo utilizar no meu projeto?”, “O EF é performático o suficiente para fazer isso?”, “Tenho uma rotina de acesso a dados lenta, o que devo fazer?”, “Qual a melhor formar de construir minha camada de acesso a dados?”, etc. A resposta para todas essas perguntas é basicamente a mesma. E sempre acabo me referindo ao ADO.NET como um aliado muito forte (e presente) nas aplicações que desenvolvo. Fato este que gera muita surpresa em todos.
A construção de camadas de acesso a dados é complexa e exige cuidados. Nos últimos anos muito se tem dito e apoiado o uso de ferramentas de mapeamento objeto-relacional (ORM). Tomo como exemplo este blog, onde muitos de meus posts são sobre o Entity Framework.
Outro dia me deparei com a seguinte exception ao renderizar um report local:
The Hidden expression for the subreport ‘<DataSetName>’ contains an error: Request for the permission of type ‘System.Security.Permissions.SecurityPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’ failed.
Quando processamos um report localmente (leia: fora do Reporting Services) e o Report Viewer carrega uma expressão associada com um assembly, é criado um sandboxed Application Domain (AppDomain) na memória. Esse AppDomain é criado com um conjunto de restrições de segurança.
A combinação de Windows Server 2012 com IIS 8.0 (ou IIS 8.5) pode funcionar um pouco diferente da combinação Windows Server 2012 com IIS 7.5.
Algumas alterações na funcionalidade Schannel Security Support Provider (SSP) impactaram no funcionamento do modelo de segurança e autenticação de aplicações. O SSP inclui recursos como Transport Layer Security (TLS), Secure Sockets Layer (SSL), e Datagram Transport Layer Security (DTLS). Todos esses recursos são muito importantes, pois envolvem tarefas de segurança e autenticação de aplicações.
Para que um serviço seja consumido via NetTcp no IIS, uma série de passos devem ser tomados. E o objetivo deste post é demonstrar como essa configuração pode ser feita.
Por que utilizar NetTcp? Este é o modelo de binding mais eficiente, este modelo é baseado no padrão TCP (Transmission Control Protocol). É bastante utilizado na comunicação entre serviços e dentro de ambientes de intranet. Este modelo de binding é indicado quando queremos fazer uso de um tráfego seguro e confiável.
Por que utilizar o NetTcp no IIS? Por diversas maneiras: (1) se um serviço exposto em um Windows Service tiver um estouro de exceção, então o serviço torna-se offline; (2) serviços expostos em consoles não são confiáveis, robustos e executam no contexto do usuário logado no Windows; (3) IIS é o serviço mais confiável, possui recursos de starting automático e recycling, além de possuir diversos recursos de monitoramento.
Leia mais »
Apesar dos dois tipos de dados compilarem normalmente quando os utilizamos em um query method, existe uma diferença no modo como as queries do Entity Framework são criadas quando utilizamos Expression<Func<T, bool>> e Func<T, bool>.
Quando utilizamos Expression<Func<T, bool>> o Entity Framework reconhece a expressão existente e a transforma em código SQL.
Mas, quando utilizamos Func<T, bool>, a função é compilada em Intermediate Language, e não é transformada em código SQL. Desta forma o filtro é feita em memória, logo após o load dos dados vindos do banco de dados.
Fernando Henrique Ferreira 