.NET Memory Fragmentation

Olá pessoal,

Gostaria de compartilhar alguns links de materiais que considerei bastante úteis quando tive que identificar problemas de Fragmentação e Falta de Memória em .NET.

Abração,
Paulo Ricardo Stradioti

Design Patters – Singleton

Este post utiliza em seu contexto e exemplos a linguagem de programação C# (CSharp).

O padrão Singleton com certeza é um dos mais conhecidos entre os desenvolvedores. Talvez seja por que ele é relativamente simples, ou, então, por que é muito amado e muito odiado por seus defensores e opositores, respectivamente. Seja como for, é um padrão que tem seu valor e sua utilização dependerá do cenário que você, Arquiteto ou Desenvolvedor, precisa resolver, por isso, não devemos desprezar seu valor.

Continue reading “Design Patters – Singleton”

C# Anti Patterns

Se você já possui algum tempo de experiência como desenvolvedor, deve ter percebido que alguns problemas (requisitos) são muito recorrentes durante o nosso trabalho.

Para citar apenas alguns exemplos, esses problemas vão de garantir que exista apenas uma instância de um determinado recurso no sistema (Singleton Design Pattern), passando pela execução de comandos/ações (Command Design Pattern) e o encapsulamento de um objeto complexo a fim de simplificar o seu uso (ou, então, de um componente que será substituido no futuro) (Proxy Design Pattern). Esses são problemas com os quais nos deparamos quando estamos codificando. Existem alguns problemas que devem ser resolvidos antes mesmo de partimos para o código, por exemplo, como a aplicação será estruturada (Architectural Patterns, ou padrões de Arquitetura, ajudam a resolver esses problemas).

Assim, ao ter que implementar os mesmos requitisos/resolver os mesmos problemas várias e várias vezes, é comum que você caia na repetição (repeat yourself). É exatamente essa repetição que deu origem aos Padrões (Patterns). Entretanto, os Patterns possuem algo de especial, eles não são simplesmente uma maneira repetitiva de resolver um determinado problema, eles são justamente a melhor maneira para se resolver aquele problema. Assim, é coerente dize que para cada um dos problemas recorrentes identificados, existe uma maneira otimal para resolvê-lo e essa menira otimal é o Pattern.

Por outro lado, da mesma forma é possível repetir boas soluções para determinados problemas, também é plausível que sejam repetidos erros ou práticas ruins. Sim, é possível que eu ou você tenhamos cometido o mesmo erro várias e várias vezes.. essa repetição acontece, em geral, até que você descubra que o que você está fazendo ou está errado e introduzirá potenciais bugs no código ou, então, não faz sentido para a linguagem/framework no qual você está trabalhando. Alguns desses erros / práticas sem sentido foram identificadas como sendo praticadas por vários desenvolvedores e, por terem se tornado comuns, receberam o nome de Anti Patterns (Anti Padrões).

É seguro afirmar que a maioria dos Anti Padrões são praticados pelos seguintes motivos:

  • Falta de conhecimento da plataforma/linguagem/framework utilizado
  • Utilização de técnicas defensivas de programação que são utilizadas e fazem sentido em outras linguagens

Se você estiver confuso, dê-me mais alguns parágrafos até examinarmos alguns exemplos, acredito que tudo fica mais claro com a prática.

Antes de examinarmos com mais detalhes alguns exemplos, vejamos algumas características que permitem identificar um Anti Pattern.

  • O código/a prática não resolve o problema
  • O código/a prática falha em algum ou vários cases de extremidade (edge-cases)
  • O código/a prática contém código que é lento e não performa quando sob alta demanda
  • O código/a prática contém código ilegível
  • O código/a prática contém código reduntante (que não tem nenhuma ação prática)

 

(CONTINUA)

  

KnockoutJS e ASP.NET MVC

KnockoutJS é um Framework JavaScript que segue o padrão MVVM (Model-View-ViewModel).

Padrões são guidelines, orientações que auxiliam na resolução de problemas comumente encontrados no Desenvolvimeto e Projeto de Software. O padrão MVVM é usualmente considerado como uma evolução do padrão MVP (Movel-View-Presenter que, por sua vez, surgiu de uma evolução do padrão MVC) por não precisar de uma referência direta para a View (como acontece no MVP) e, assim como seus precursores, também propõe a separação de responsabilidades (a exemplo, lógica de negócio e dados da interface).

O padrão MVVM foi, originalmente, proposto por John Gossman em 2005 para o desenvolvimento de aplicações WPF e é muito parecido com o Presentation Model, proposto por Martin Fowler em 2004. Ambos (Presentation Model e o MVVM) propõem uma abstração da View. A principal diferença, entretanto, se da no fato de que Martin Fowler propôs o PM para fornecer uma abstração da View independente de plataforma, enquanto John Gossman introduziu o MVVM como uma padronização que aproveitava as características do WPF para construção de interfaces, sendo, praticamente, uma especialização do Presentation Model.

Com o passar do tempo, o padrão MVVM foi se difundindo e se desvinculou do WPF, como no caso do Knockout, que foi construído utilizando JavaScript.

Vejamos as responsabilidades de cada uma das partes do MVVM:

Model
É responsável pelos dados e a pela lógica de negócio da aplicação Por exemplo, Clientes, uma lista de contatos, regras matemáticas utilizadas para cálculo de uma projeção, etc.

View
A View é responsável pela aparência da aplicação e por fornecer controles com os quais os usuários interagem. Os dados podem ser exibidos pela view através de um mecanismo conhecido como DataBind, que permite fazer a vinculação entre propriedades (a propriedade Text de um Label a propriedade Nome de um objeto em memória, por exemplo).

ViewModel
Utiliza um ou mais Models para expor propriedades, que depois são bindadas às Views e também passa comandos para o Model.

image

A View tem conhecimento do ViewModel, mas não do Model. O ViewModel, por sua vez, tem conhecimento somente do Model. E o Model não tem conhecimento das outras duas partes.

Entre as vantagens em se utilizar o padrão MVVM podemos citar:

  • Melhora na integração entre Designers e Desenvolvedores
  • Facilita a troca da Interface de Usuário
  • Melhora a extensibilidade do projeto
  • Melhora a estruturação do sistema
  • Facilita a manutenção
  • Separação de responsabilidades
  • Melhora a testabilidade
  • Reduz o tempo de desenvolvimento
  • Facilita a customização das aplicações

Nos próximos posts vou postar exemplos de como utilizar o KnockoutJS nas Views do ASP.NET MVC, permitindo a implementação MVVM no browser.

Technorati Marcas: ,,,

Configurando o Beyond Compare no Visual Studio 2010 e Team Foundation Server

Se você está acostumado a trabalhar com o Visual Studio conectado ao Team Foundation Server já deve ter se deparado com uma situação de conflito de versões em que é necessário fazer uma combinação entre a versão do repositório e a versão com as alterações. Muito embora o Visual Studio e o TFS tenham uma ferramenta que possibilite fazer o merge, ela possui pouca flexibilidade.

Uma ferramenta (comercial) que gosto bastante é o Beyond Compare. Você também pode utilizar uma alternativa gratuita como o WinMerge, por exemplo.

Para configurar o Beyond Compare para ser utilizado com o Visual Studio e o Team Foundation Server bastam alguns passos simples:

  1. No menu Tools, escolha a opção Options.
    image
  2. Na árvore de opções à esquerda, expanda Source Control e selecione o item Visual Studio Team Foundation Server.
    image
  3. Clique no botão Configure User Tools…
  4. Na janela que se abrir, precisaremos inserir duas configurações: uma para Comparação e uma para Combinação (Merge).
    image
  5. Clique no botão Add…
  6. Preencha o formulário de acordo com a Tabela abaixo
    image
  7. Item

    Compare

    Merge

    Extension

    .*

    .*

    Operation

    Compare

    Merge

    Command

    <caminho para o BeyondCompare.exe>

    <caminho para o BeyondCompare.exe>

    Arguments

    %1 %2 /title1=%6 /title2=%7

    %1 %2 /savetarget=%4 /title1=%6 /title2=%7

Agora você já pode utilizar os recursos de Compare e Merge do Visual Studio e os fontes serão abertos no Beyond Compare.

Desenvolvimento de Aplicações com HTML 5 e CSS3

Desenvolver uma aplicação que rode em diversas plataformas é um sonho de consumo antigo para empresas e profissionais que trabalham com o desenvolvimento de sistemas. O Java foi a primeira tentativa com certo sucesso de transformar isso em realidade. Também podemos citar alguns frameworks, como o PhoneGap e o projeto Mono – que disponibilizou alguns recursos do .NET Framework para ambientes Linux.

Entretanto, o mercado parece estar convergindo para uma tecnologia até então pouco promissora para a construção de aplicativos multiplataforma: o HTML. Mas para que isso fosse possível o HTML teve de se reinventar. Fugir das limitações das versões iniciais e incorporar recursos que se tornaram indispensáveis em praticamente qualquer website. Questões de compatibilidade/renderização entre os browsers, utilização de áudio e vídeo e validação de formulários se tornaram drasticamente mais simples a partir do momento em que foram incorporadas à linguagem HTML. Não são necessários mais plugins, controles, applets e toda a infinidade de macetes que os desenvolvedores eram obrigados a utilizar para fazer com que as páginas Web funcionassem como deveriam.

O HTML5 foi resultado de uma observação detalhada de como as páginas Web estavam sendo construídas: com muita repetição de código e utilização de artifícios para compatibilização entre browsers. Uma vez terminada a especificação do HTML 5 (em dezembro de 2012), espera-se que os principais browsers – pelo menos os mais sérios – implementem à risca a espeficiação do W3C e que surja uma nova fase no desenvolvimento de aplicações Web. A partir de então, desenvolver esse tipo de aplicação torna-se uma experiência integrada e não uma batalha contra os browsers.

Conforme avançar meus estudos sobre HTML 5 farei novos posts no blog. Mas deixo aqui uma pergunta que pode ser bem aproveitada se discutida em grupo: Muito embora seja possível detectar se determinada funcionalidade do HTML 5 é suportada pelo browser do usuário, como podemos garantir a confiabilidade da aplicação sendo que muito do trabalho de desenvolvimento foi incorporado ao HTML5? Se o usuário utilizar um Browser que não suporta determinada funcionalidade devemos ter um plano de backup e oferecer uma versão desenvolvida especificamente para browsers antigos (o que implica o mesmo esforço de desenvolvimento anterior ao HTML5) ou pedimos gentilmente que ele atualize seu browser (o que, eventualmente, pode ser uma decisão do administrador de redes e que depende de homologação por parte da empresa, tornando seu site inacessível por um determinado grupo de usuários)?

Por enquanto, só posso dizer que estou animado com as possibilidades da tripla (HTML5; CSS3; JavaScript). Parece que finalmente estamos convergindo para uma plataforma única para o desenvolvimento de aplicações! Alegre

Caso você queira aprender mais sobre HTML5 e CSS3 seguem deixo aqui uma sugestão de material bem bacana: curso (em inglês) do Microsoft Virtual Academy Developing in HTML5 with JavaScript and CSS3 Jump Start e para praticar e desenvolver suas primeiras aplicações (de graça!) você pode utilizar o Visual Studio Express 2012 for Web.