.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 Lendo “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)

  

ASP .NET MVC – Introdução

Antes de falarmos da tecnologia propriamente dita, é salutar entender como surgiu o conceito do MVC.

O termo MVC (Model – View – Controller) foi, originalmente, proposto por TrTrygve Reenskaugygve Reenskaug, que era desenvolvedor Smalltalk, enquanto participava de um projeto para desenvolver um computador portátil que conteria todos os dados de interesse para seu usuário ou dono (Dynabook). Além disso, esses dados também deveriam incluir os programas utilizados para manipulação deles e o usuário/dono deveria ter a possibilidade de entender e escrever programas, aumentando seu domínio sobre o sistema.  Reenskaug mantém um site, onde explica com suas próprias palavas o conceito MVC, que ele desenvolveu em 1978. No site também é possível encontrar um artigo através do qual Reenskaug apresenta sua teoria para a comunidade internacional.

Se você quiser acessar uma breve descrição do significado dos termos Model, View e Controller, por favor, acesse este post no meu blog ou então aguarde o desenvolvimento deste séria de posts sobre ASP.NET. Ao longo dos posts estes conceitos ficarão mais claros e você poderá associá-los facilmente com a parte tecnológica, que coloca isso tudo para funcionar! Alegre

O ASP.NET MVC, por sua vez, é um Framework de desenvolvimento Web que segue as linhas do padrão de arquitetura MVC, o que nos permite aproveitar ao máxico a eficácia do padrão [MVC] e as idéias mais recentes de desenvolvimento ágil, sem perter todo o poder da plataforma ASP.NET.

Para entender por quê o ASP.NET MVC têm ganhado tanta importância, vamos fazer uma breve análise da evolução do Desenvolvimento Web com a plataforma Microsoft:

 

1993

  • CGI – Common Gateway Interface
    • Era uma maneira flexível de gerar conteúdo dinâmico. No início era a única alternativa para gerar conteúdo mais elaborado ou interativo. Trata-se de uma forma de comunicação entre o servidor Web e um programa executável arbitrário que retorna um conteúdo dinâmico. Foi inicialmente proposto pela NCSA – National Center of Supercomputing Applications, mas não é mais mantido pela entidade.
      (Não era mantido pela Microsoft, mas merece destaque por ser o precursor da Web Dinâmica)

1996

  • ASP – Active Server Pages
    • Na época representou um avanço para o desenvolvimento web, permitindo a criação de conteúdos dinâmicos de propósito geral. Entretanto, era interpretada em tempo de execução (e com todos os problemas a que isso tem direito) e tornava resultava em um código emaranhado, que misturava a lógica da apresentação com sua apresentação (código HTML). Essa mistura e comumente conhecida como código espaguetti. Fica difícil seguir uma linha de raciocínio quando se têm um código tão emaranhado.

2002 – 2003

  • ASP.NET Web Forms 1.0/1.1
    • Representou uma mudança radical nos paradigmas de desenvolvimento Web. O código era compilado, a interface de usuário permitia a preservação do estado (o valor/estado dos objetos da interface se mantinha entre as várias requisições/post-postback nas páginas). Foi a primeira tentativa de oferecer um padrão com divisão em camadas e um “encapsulamento” do Desenvolvimento Web. Entretanto, a maneira como o funcionamento dos Web Forms foram projetados levava a um aumento no consumo de banda (tanto por parte dos servidores quanto por parte dos clientes), pois para que os controles pudessem manter a seu estado, uma quantidade extra de informação era gerada e enviada para o cliente e, depois, novamente enviada para o servidor, causando um overhead na comunicação entre os dois. Além disso, os projetos ASP.NET Web Forms são extremamente difíceis de testar e geravam (até a versão 4.0 do Web Forms) um resultado HTML extremamente complexo e difícil de integrar com JavaScript.

      Por encapsulamento do Desenvolvimento Web, refiro-me à preservação do estado, já que o funcionamento das resições Web são, por natureza, sem preservação de estado e pelo mecanismo utilizado pelo ASP.NET Web Forms para associar os eventos de interface à execução do código compilado no lado servidor. Muitas vezes, quando era necessário manipular os controles dinamicamente essa “amarração” entre o evento na interface do usuário (por exemplo o clique em um botão) e a execução do código correspondente àquela ação no lado servidor simplesmente não funcionava, além dos famosos erros de View State.

2005

  • ASP.NET Web Forms 2.0
    • Foram introduzidos vários controles/componentes que reduziam a quantidade de código que os desenvolvedores precisavam construir. Veja mais sobre as novidades do ASP.NET 2.0 neste artigo da MSDN Magazine.

2007

  • ASP.NET AJAX
    • Foi a resposta da Microsoft ao aumento da popularidade do AJAX, permitindo uma melhor interatividade no lado cliente das aplicações.

2008

  • ASP.NET Web Forms 3.5
    • Foram incluídos novos controles, como o ListView e o LinqDataSource. Veja mais sobre as novidades do ASP.NET 3.5 aqui.

2009

ASP.NET MVC 1.0

2010

  • ASP.NET MVC 2.0
  • ASP.NET Web Forms 4.0
    • Pela primeira vez o ASP.NET Web Forms começa a respeitar mais seriamente os padrões Web.

2011

  • ASP.NET MVC 3.0

2012

  • ASP.NET MVC 4.0
  • ASP.NET Web Forms 4.5

 

É importante entender que o ASP.NET Web Forms é um conjunto de componentes de interface dotados de um modelo de programação com preservação de estado e orientado à objetos. Esses compoentes são construídos e rodam sobre uma base, que é o ASP.NET.

image

 

O ASP.NET, por sua vez, roda sobre a base do .NET Framework, que fornece uma série de recursos e ferramentas para desenvolvimento, teste, deploy, execução e depuração de aplicações.

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.

Formatar Código SQL (SQL Server)

Olá pessoal!

Hoje quero compartilhar uma dica de recurso para formatação de código SQL. É comum no dia a dia encontrarmos instruções SQL de centenas de linhas completamente confusas e desformatadas.

Nessa hora, eu apelo para o Poor Man’s T-SQL Formatter. O mais legal é que ele está disponível em uma variedade de aplicativos:

  • Plugin para o SQL Management Studio (SMS)
  • Plugin para o editor Notepad++
  • Utilitário Linha de Comando para formatação de arquivos em Lote (imagine uma pasta com uma série de procedures, todas com código desformatado e praticamente incrompreensível)
  • Aplicativo independente, que além de formatar o código permite visualizar árvore de parsing
  • Plugin para o WinMerge,  uma ferramenta gratuita de comparação e merge para Windows
  • Online, em http://poorsql.com
  • Biblioteca para ser utilizada em suas aplicações (Frameworks 2.0/3.5)

É isso aí!

Deixe um comentário com sua avaliação do Plugin, esse tipo de informação é importante para quem procura esse tipo de recurso.

Abração.

Paulo Ricardo Stradioti

Próximo Passo: Mergulhe de cabeça na Imagine Cup! #MSPTeam2011

Você já decidiu que quer fazer a sua parte! Então é hora de traçar estratégias. O pessoal da Proativa deu várias dicas sobre como eles conseguiram chegar lá, mas antes, vamos conhecer um pouquinho da história dessa galera.

Lucas, Flavio e João Paulo já estavam acostumados a fazer os trabalhos em grupo juntos. Daí até montar uma célula acadêmica foi apenas um empurrãozinho, dado por uma palestra da qual eles participaram no Centro de Informática na UFPE.  Também interessado nas células, o Amirton entrou para o grupo. Decidiram então que queria participar da Imagine Cup.. Em 2008 o time inscreveu um projeto mas não chegou às finais nacionais.

Certamente isso causou uma frustração, afinal, foi tanto trabalho jogado fora! Em vez de desistirem, em 2009 a galera ponderou todos os erros e acertos, pediu dicas com quem já percorreu e conhecia o caminho. Evitando os erros e seguindo as dicas o grupo conseguiu chegar às finais mundiais da categoria de Interoperabilidade.

Apresentaram o projeto para os juízes. A sinergia de tecnologias funcionava tão bem que eles trouxeram a taça para a casa.

Realmente ganhar uma competição com o porte da Imagine Cup não deve ser nada fácil, Mas a Proativa é a prova de que se pode sair do ZERO e chegar ao TOPO com determinação, foco e comprometimento. Essas palavras foram fundamentais para que o grupo conseguisse amadurecer a idéia e chegar a um projeto comercialmente viável e que conseguisse ajudar a resolver o problema.

Segundo Lucas, conciliar os estudos na faculade com o projeto Imagine Cup não foi fácil. Eles precisaram abdicar de coisas das quais gostavam muito em favor de um sonho, de um objetivo. Foram finais de semana gastos em códigos e reuniões enquanto as namoradas, as famílias ficavam na torcida. Esse é o preço que se paga por um sonho! É o quanto custa dizer para si mesmo que você quer chegar onde até então jamais tinha imaginado.. E o melhor, quando você consegue, todos vêm que o sacrifício vale a pena e se diespõem a passar por tudo novamente se fosse necessário!

As principais dúvidas quando se fala em Imagine Cup são:

1) Como montar um time? Quem convidar?

2) Como ter uma idéia bacana?

3) Como transformar essa idéia em um projeto vencedor?

Segundo Lucas, o time Proativa nasceu a partir de uma afinidade entre os membros. Objetivos comuns e amizade! O tempo provou que as competências entre eles se complementavam… Enretanto, você pode adotar uma postura mais objetiva. Convide um Designer, um marketeiro e desenvolvedores bons e criativos. Dessa forma você tem um time que se completa, capaz de suprir todas as necessidades imediatas do projeto.

Ou então, apenas convide seus amigos e decidam entre vocês quais tarefas cada um faz melhor.

Outro ponto muito importante destacado em uma das conversas que tive com o Lucas é que, segundo ele, é muito difícil uma idéia já nascer campeã. As idéias surgem como estalos, quando você menos espera: viajando no ônibus, tomando banho, lavando a louça, estudando, etc.. Quando você força demais seu cérebro a produzir algo criativo, o estresse toma conta dele e nada de criativo é capaz de nascer. Boas dicas para inspirar, segundo textos na internet, é visitar uma galeria de artes, ouvir música, ler matérias relacionadas ao assunto sobre o qual se deseja criar algo, conversar com pessoas envolvidas com a área.. Enfim, encha seu cérebro de informação, de conteúdo, faça-o trbalhar!

Depois parta para o seu programa favorito: praticar esportes, passear, jogar jogos eletrônicos, enfim.. faça algo que lhe dê prazer! É nessa hora que a região criativa do cérebro é ativada e, com tanta informação que você já deu para o seu cérebro, ele terá material suficiente para trabalhar.

A idéia surgirá pequena, talvez meio desajeitada ou estranha. É o diamante bruto! Será necessário transformá-lo em uma jóia que faça os olhos dos jurados brilharem..

Você poderá fazer isso valendo-se de vários artifícios:

  1. Discuta muito a idéia com seu grupo
  2. Converse com professores
  3. Procure especialistas no assunto
  4. Encontre alguém envolvido com economia, finanças e áreas afins para conseguir dicas de como enquadrar o Projeto em um perfil comercial

Depois parta para a ação! Construa um protótipo e tente realizar simulações, aplicá-lo com a supervisão de especialistas da área. Certamente será necessário construir ajustes, transformar a idéia concebida em um projeto que atende às necessidades de casos reais.

Você já deve ter percebido que a construção de um projeto campeão leva tempo, é iterativa.. deve ser pensada, repensada e adaptada. Por isso, outra dica muito importante do pessoal da Proativa é não deixar para desenvolvê-lo de última hora.

Confirma uma sugestão de Roadmap, considerando-se que as inscrições para a Imagine Cup 2011 estão praticamente todas encerradas:

  1. Defina seu critério e convide membros para fazer parte de uma célula acadêmica;
  2. Fique atento à divulgação do tema da Imagine Cup 2012;
  3. Inicie as leituras em periódicos, revistas, internet, etc relacionados ao tema;
  4. Faça os primeiros brainstormings (tempestade de idéias) com o grupo;
  5. Escolham a patinha feia (a idéia desengonçada que precisa ser transformada em Cinderela);
  6. Trabalhem a idéia, discutam, procurem dicas com especialistas;
  7. Inicie o desenvolvimento do protótipo;
  8. Valide o protótipo em campo, junto a especialistas da área
  9. As finais da Imagine Cup estão às portas, agora é só torcer!

Agradeço muito ao Lucas e à equipe da Proativa por todas as dicas que eles compartilharam. Embora minha equipe e eu tivéssemos participado das finais nacionais da Imagine Cup em 2008, nosso projeto não tinha condições para ser campeão, exatamente pelo fato de sermos muito imaturos e completamente inexperientes em Imagine Cup. Nos anos subsequentes a falta de tempo e desmotivação da equipe fizeram com que não inscrevêssemos projetos.

Mas e em 2012, nos vemos nas finais?!

Um forte abraço!

 

 

Paulo Ricardo Stradioti
Microsoft Student Partner