Criação de aplicação com boas práticas de arquitetura
Para quem quiser acompanhar, o Ayende Rahien(MVP) irá construir uma aplicação do zero, utilizando boas práticas de arquitetura de software. Diferente da maioria dos exemplos, desta vez não será locadora, biblioteca, ou até mesmo restaurante, será algo mais inusitado, o gerenciamento de uma prisão. Acho que vale a pena acompanhar.
Link da aplicação: http://ayende.com/Blog/archive/2009/07/27/macto-or-how-to-build-a-prison.aspx
Para quem não conhece o Ayende, ele é um dos contribuidores do NHibernate.
Provavelmente, vocês verão uma aplicação que não será distribuída(fisicamente), mas será distribuída em camadas lógicas, entretanto, as técnicas aplicadas ao domínio do problema são válidas e acredito que estará repleta de patterns utilizados na prática, e caso queiram expandir para uma aplicação distribuída fisicamente, bastaria criar uma camada de serviços nos servidores de aplicação(há outras questões que precisam ser discutidas) , utilizando, por exemplo, o WCF para comunicações com a camada de apresentação. Criar tudo em apenas uma máquina não é errado, é apenas um outro tipo de arquitetura.
Obviamente, diferente de uma aplicação distribuída, estas máquinas ao invés de especializadas para determinado cenário de utilização, serão mais potentes, e quando é necessário escalar a aplicação, é necessário colocar mais uma máquina no cluster, contendo um espelho da aplicação(técnica que o Windows Azure utiliza). Outro ponto legal da aplicação, pelos insights que vi, é que ela utilizará um Mapeador Objeto Relacional(ORM) que será o NHibernate(concorrente do Entity Framework da Microsoft, só que bem mais maduro, pelo menos até a versão corrente do EF).
No texto acima deixei diversos links com os conceitos e ferramentas.
Para quem não está acostumado com este cenário, é uma excelente oportunidade de aprendizado.
Vamos aguardar os próximos capítulos.
[]'s
Fabio Margarito
O perigo da concatenação de strings
Trabalho em uma grande instituição financeira e esta semana tivemos um problema sério de alto consumo de memória de um único processo, em um servidor de aplicação extremamente acessado. O consumo exagerado era de um processo de Cache, ele estava com quase 1GB de memória alocada.Bom, sendo um processo de Cache isto pode ser uma verdade em muitas situações, entretanto, a informação armazenada em Cache no momento, era de apenas 20 MB, portanto, 1GB alocado é algo fora dos padrões.
Descobrir memory leak não é uma tarefa muito fácil, realizar um Code Review pode ser uma solução, pois podemos percorrer o código e procurar por causas que podem determinar esta condição. Mas há um porem, se a aplicação for muito grande, isto pode demorar muito,e demorar a encontrar um problema de produção é muito grave para nosso setor de atuação.Quando há qualquer tipo de problema em produção, preferimos realizar análise de Dump por ser mais rápido.
O Dump do processo é gerado pelo pessoal de produção que nos encaminha para análise. Análise de Dump é uma técnica de debug onde analisamos a memória de um processo. No fim deste post, deixo algumas referencias para quem gosta de desafios.
Vamos lá, para realizar a análise vamos utilizar o programa WinDbg:
Pela opção File/Open Crache Dump, vamos carregar o Dump.
Agora vou carregar a DLL SOS.dll, esta DLL fornece comandos para manipular Dump de código gerenciado. Para cada versão do .Net Framework, há uma versão diferente. No caso, estou carregando a Dll do framework 2.0
Como é um memory leak, vou direto ao comando !dumpheap -stat. O objetivo deste comando é trazer estatísticas de consumo de memória por tipo. O resultado é expresso em bytes. Dependendo do tamanho do dump, o resultado poderá demorar um pouco. Por motivos de confidencialidade, estou ocultando algumas informações.
Achamos os vilões. Percebam que o tipo System.String ocupa 560 MB e temos em torno de 400 MB com objetos prontos para serem liberados. Somando, temos quase os 1GB de memória consumida. É um tanto estranho o tipo System.String ocupar tanto espaço não?Agora vamos recuperar todos os 281 mil objetos do tipo string. Para esta tarefa vamos usar o comando !dumpheap -mt 793308ec.
Como são milhares de objetos, vamos pesquisar por amostragem. A idéia é buscar a raiz de cada objeto. Para realizar esta busca, vamos utilizar o comando !gcroot <endereço do objeto>, no caso !gcroot 3dc31000.
Temos um suspeito agora, o CacheCleanup. Varrendo outros objetos percebi que todos têm a mesma raiz, ou seja, provavelmente o problema está lá. Abaixo um trecho do código danoso:
#region Access Log
Handler.LogHandler.Tracking("Access Method: " + this.GetType().ToString() + "->" + ((object)MethodBase.GetCurrentMethod()).ToString() + " ;");
#endregion Access Log
Como podemos ver, o código está cheio de concatenações em um trecho crítico do projeto que trata traces, e este é chamado milhares de vezes. Concatenação de string com o operador + não é uma boa prática devido à maneira que ocorre a manipulação de memória. Mais informações você pode encontrar neste site. Para corrigir, apenas substituí por String.Builder e o problema foi resolvido.
Links
Blog da Tess Fernandes tem tudo sobre debug
Debugging Tools for Windows
Conclusão
O que pode ser algo inofensivo, em cenários onde há milhões de chamadas em curto espaço de tempo pode se tornar uma dor de cabeça sem precedentes e custar muito $$$$$.
[]’s
Fabio Margarito
Integração contínua – Parte 1
Vou iniciar uma série de posts sobre o processo de integração contínua e como utilizar ferramental de apoio parar tornar a prática possível.A idéia de montar a série advém de dúvidas de amigos e para eu mostrar como este processo trouxe benefícios ao meu trabalho.Inicialmente irei contextualizar o que é Integração Contínua e como utilizar ferramental apropriado, e na seqüência vamos implementá-la utilizando uma plataforma open-source na prática com Cruise Control + nant e também através do Team Foundation 2010(se tudo der certo).
Em uma tradução livre, Fowler define integração contínua como :
“Uma prática de desenvolvimento de software onde os membros de um time integram trabalhos com frequência, usualmente cada pessoa realiza integrações pelo menos uma vez ao dia – levando a múltiplas integrações por dia. Cada integração é verificada por um processo de build automático para detectar erros de integração o quanto antes. Muitos times acham que esta abordagem leva a reduções drásticas de problemas com integração e permite que um time desenvolva softwares coesos rapidamente”.
Para entender as palavras de Fowler, vou demonstrar como funciona o trabalho de um time quando uma nova versão de sistema é desenvolvida:
- Cada desenvolvedor baixa uma cópia dos fontes de um repositório central para sua máquina. Este repositório é o Source Control. Não é objetivo discutir nesta série o papel e recursos de um Source Control e por isso indico o excelente artigo do Eric Sink, caso Source Control seja um assunto desconhecido para você.
- Cada desenvolvedor efetua o check-out, ou seja, “informa” ao source control que determinado fonte está sendo alterado e mantém este estado pelo tempo necessário até efetuar a alteração.
- Após alterações de fonte, que podem levar vários dias, cada desenvolvedor efetua o “check-in”, que é o processo de enviar para o source control o código alterado e torná-lo disponível a todos.
- Quando todos os desenvolvedores efetuarem os check-ins, uma profissional baixa a versão e realiza o Build. O Build é o processo de montagem de uma versão que será implantada, e pode ser composto por uma compilação, montagem, execução de scripts de banco de dados, entre outros artefatos. O processo de Build realizado através dos check-ins é o processo de integração que Fowler cita, ou seja, quando integramos o resultado do trabalho de todo time. O Build é um processo chato, oneroso, geralmente de natureza manual e leva muito tempo.
- O resultado oriundo do Build é instalado.
Este é o caminho feliz, mas geralmente não é verdade, por quê? Um módulo alterado por um desenvolvedor pode afetar o trabalho de outro, devido a erros de código ou quebra de compatibilidade. Estes problemas normalmente são encontrados em vias de entrega da versão.
A Integração Contínua tem como principal objetivo, automatizar todo processo de Build para que erros possam ser identificados o quanto antes. Por ser um processo automático, a freqüência de integração aumenta. É boa prática que o time realize check-ins diários para que tirem proveito do processo de integração contínua.
Ferramentas de integração contínua (IC) podem, por exemplo, identificar que houve check-in de arquivos e automaticamente disparar um processo de Build, se houver algum erro, um aviso pode ser emitido e problema identificado rapidamente. Caso o processo de Build seja muito lento, o mesmo pode ser agendado para rodar noturnamente todos os dias.Outro recurso interessante de ferramentas IC, é a possibilidade de após Build, rodar testes automatizados, caso um teste não passe, um erro de Build é gerado.
Espero que nestas poucas linhas, eu tenha conseguido deixar claro o que é o processo de integração contínua e quais benefícios o time ganha com esta prática. No próximo post, vamos começar a colocar a mão-na-massa, utilizando o Cruise Control.
Para mais informações, sugiro os links:
Continous Integration na visão de Martin Fowler
http://www.martinfowler.com/articles/continuousIntegration.html
Continous Integration por Mattew Foemmel
http://www.martinfowler.com/articles/originalContinuousIntegration.html
[]'s
Fábio Margarito
12º Reunião do Grupo .NetArchitects
No sábado(17/07), houve o 12º encontro do grupo .Net Architects. Desta vez o tema foi WCF(Windows Communication Foundation) o qual foi apresentado pelo Rafael Godinho especialista em desenvolvimento do grupo de evangelização de tecnologias da Microsoft. O Rafael abordou vários assuntos interessantes com propriedade, passando pelo básico e alternando entre conceitos e exemplos práticos, ou seja, agradou a quem não conhecia quase nada, e trouxe novos conhecimentos aos que já trabalham com esta tecnologia.
Alguns tópicos:
- O que é WCF?
- O que não é WCF?
- Definição do termo serviços
- Serviços REST com WCF
- Hospedagem de serviços WCF
- Cenários de utilização
Logo em seguida fomos para a discussão saindo de WCF, passando por ESB(Enterprise Service Bus), EAI(Enterprise Application Integration) e até por OSLO. Pena que não conseguimos gravar a discussão devido a problemas técnicos, e por isso recomendo a reunião presencial.Outro ponto positivo da discussão foi ter a oportunidade de trocar idéias com profissionais que dificilmente teríamos contato de outra forma, como o Waldemir Cambiucci, arquiteto de solução da Microsoft e MVPs como o Giovanni Bassi.
Alguns Links úteis:
E a próxima reunião será sobre OSLO com o Waldemir Cambiucci.
[]'s
Fábio Margarito
Cliente de Twitter em WPF - Blu
Encontrei um excelente exemplo de interface com WPF, um cliente de Twitter o Blu! Para instalar é muito fácil, basta ir ao site do blue e "clicar" em download.
Alguns pontos fortes:
- Visual fantástico, cheio de efeitos especiais :-).
- Integração com o TinyUrl. Quando você inclui um link, o Blu automaticamente cria uma url TinyUrl, recurso muito útil, pois temos uma quantidade de caracteres limitada.
O que não gostei:
- Ficou faltando uma opção para rodá-lo no tray
- Possibilidade de seguir alguém e ver quem está te seguindo.
Microsoft divulga forma de comercialização do Windows Azure
Finalmente a Microsoft divulgou a forma de comercialização do Windows Azure. Como previsto, cobrarão por consumo. A seguir um exemplo de custo de uma máquina no Azure:
-
Por hora máquina, o custo ficará em U$ 0,12 que na cotação de hoje (R$ 1,939) sairá em torno de R$ 0,23, resultando em 166,00 reais por mês.
Achei um preço justo, pois hoje locar uma máquina dedicada sairá bem mais que isso. Claro que outros serviços também serão cobrados, como consumo de banda e storage, mas com preços competitivos. Comercialmente o Azure será disponibilizado no Professional Developer Conference 2009.
Mais detalhes: http://blogs.msdn.com/windowsazure/archive/2009/07/14/confirming-commercial-availability-and-announcing-business-model.aspx
[]’s
Novas Fotos DNAD 2009
Acabei de receber as novas fotos do DNAD 2009, tiradas pelo amigo e fotógrafo Luiz Pais. Da esquerda para a direito, Renato, Priscila, Eu, Alessandro(Spartan Boy :-) ), e o Leandro Daniel.
Acceptance Test Engineering Guide - Volume I
O Markus Christen, lançou um post sobre o Acceptance Test Engineering Guide - Volume I que acabou de sair do forno e está em beta. Li um pouco do conteúdo e está bastante interessante.
[]'s