Postado por Abel Avram para o InfoQ, traduzido por Yan Borowski em 12 Nov 2009 09:43 AM

Fabrice Marguerie, um arquiteto de software e consultor, escreveu o artigo Como detectar e evitar vazamentos de memória e recursos de aplicações. NET, publicado no MSDN. O artigo   explica como vazamentos de memória e recursos podem acontecer durante a programação para. NET e como evitá-los.

Linguagens como C #, fazendo a limpeza da casa através de um coletor de lixo de memória, não tem vazamentos de memória em seu sentido original quando perde um programa de acesso completo a um local de memória. Segundo Fabrice, vazamentos de memória ocorrem quando uma localização de memória já não é necessária, mas o programa continua a manter pelo menos uma referência a ele. O coletor de lixo iria reclamar que a memória se era inacessível, mas a memória se torna um vazamento, desde que ela é referenciada pelo programa e não é mais utilizada.

Fabrice também enumera uma série de recursos de sistema operacional que podem ser sujeitos a vazamentos similares:

• O sistema utiliza objetos do usuário para suportar o controle da janela. Eles incluem: aceleradores de tabela, Carets, Cursores, Hooks, ícones, menus e janelas.
• Suporte a Objetos GDI gráficos: Bitmaps, Brushes, Contextos de dispositivo (DC), Fontes, DCs de memória, Metafiles, paletas, canetas, Regiões, etc
• Objetos do Kernel de apoio para gerenciamento de memória , execução do processo e inter-processo de comunicação (IPC): arquivos, processos, threads, semáforos, temporizadores, tokens de acesso, Sockets, etc

Estes recursos são limitados, as chaves do Registro GDIProcessHandleQuota e USERProcessHandleQuota contendo o número máximo de objetos de usuário e GDI que um processo pode usar. Os valores padrão são 10.000 para estas alças. Embora este número seja suficiente para a maioria das aplicações, a utilização de muitas delas fará com que o sistema atinja outro limite de 65.536 alças para uma sessão do Windows. Fabrice relatou que bateu este limite muito mais cedo, em cerca de 11.000.Sua conclusão é que os recursos de sistemas devem ser cuidadosamente utilizados e liberados quando não mais necessários.

Fabrice enumera as seguintes causas de vazamentos, explicando como funciona cada um deles:

• Usando referências estáticas
• Evento com a falta de cancelamento – essa é considerada, pelo autor, como a fonte mais comum de vazamentos
• Evento estático com a falta de cancelamento da referência
• Não chamar o método Dispose
• Usando um método Dispose incompleto
• A utilização indevida BindingSource com Windows Forms
• Não usar a chamada Remove no WorkItem/CAB

O autor continua o artigo, oferecendo aconselhamento sobre como evitar vazamentos:

• O criador ou proprietário de um objeto, e não o seu utilizador, é responsável pelo escoamento
• Sempre remova a referência de um Event Listener quando a mesma não é mais necessária, isso poderia ser feito com o Dispose() para a segurança
• Quando um objeto não gera mais eventos, todos os seus Listeners devem ser removidos através da atribuição de "null" para o objeto
• Quando uma referência é usada por um Model e pela sua View, é recomendado passar   um clone   do objeto referenciado   para a View,   evitaando assim que se perca quem está usando o que
• Chamadas aos recursos do sistema devem ser colocadas em blocos com "using" que forçam automaticamente uma chamada Dispose, ao sair do bloco

Fabrice conclui pela introdução de uma série de ferramentas úteis para lidar com objetos e vazamentos: GDILeaks (EXE), dotTrace, .NET Memory Profiler, SOS.dll, WinDbg.

Fonte: InfoQ

Postado por Jonathan Allen, traduzido por Carlos Mendonça em 04 Set 2009 08:37 AM

A visão da Microsoft do .NET é abrangente. Além do desejo de suportar todas as linguagens de programação, seja diretamente, seja através de camadas de interoperabilidade, ela também quer juntar todos os frameworks de comunicação e engines de armazenamento de dados. Mas se por um lado o WCF está saindo na frente ao padronizar as APIs de comunicação, o framework universal de acesso a dados, o Entity Framework, está atrasado.

Um dos maiores problemas, até agora, é que o ADO.NET Entity Framework não veio de fábrica com suporte para os maiores bancos de dados não-Microsoft, como o Oracle. Isso trouxe a oportunidade para desenvolvedores terceiros preencherem a lacuna.

Um destes distribuidores é a Data Direct. Para muitos usuários seu maior benefício é o de ser 100% feito em código gerenciado. Normalmente isso não representa grande coisa, mas neste caso quer dizer que você pode evitar totalmente um cliente Oracle nativo.

Outro distribuidor é a Devart. A oferta da Devart já está disponível para a comunidade há mais tempo que a da Data Direct e oferece uma lista de funcionalidade comparável. E, sem nenhuma surpresa, o fato de não precisar de um cliente Oracle nativo também é número 1 na sua lista de funcionalidades.

A Oracle, em si, está estranhamente quieta nesta área. Embora ela ofereça o ODP.NET, ele está limitado aos design patterns padrões do ADO.NET.

Fonte: InfoQ

O Blog “Ravings of a Developer TS” disponibilizou uma série de links de materiais gratuitos, referentes a tecnologias Microsoft para desenvolvedores.

Vale a pena conferir em: http://blogs.msdn.com/angelab/archive/2009/07/29/hey-microsoft-coders-free-stuff-training-books-magazines-to-sharpen-your-skills.aspx

Fonte: Twitter Andre Dias

Postado por Abel Avram, traduzido por Victor Franzonatto em 11 Ago 2009 03:15 PM

Rick Strahl criou CodePaste.NET, um site que permite compartilhar .NET Code Snippets (trechos/fragmentos de código .Net) entre usuários de redes sociais e IM.

É difícil inserir código em páginas de redes sociais e janelas IM porque o código de formatação normalmente se perde, ou o número de caracteres é limitado, entre outras razões similares. CodePaste.NET permite qualquer um colar Code Snippets em uma caixa de texto e, em seguida, clicar em um botão Colar. O trecho (snippet) recebe uma URL que pode ser copiada a partir da barra de endereços do navegador e distribuída. Qualquer pessoa pode visualizar o snippet, e os usuários cadastrados podem comentar e editá-lo. Desta forma, trechos de código podem ser enviados até mesmo ao longo do Twitter.

O site oferece sintaxe highlighting para as seguintes linguagens: C#, VB.NET, JavaScript, HTML, ASP.NET, JavaScript, XML, CSS, SQL, T-SQL, e FoxPro. Numeração da linha de código pode ser habilitada, e o código pode ser copiado para a área de transferência com um clique.

Os snippets podem ser recuperados como JSON, XML usando “?format=json” (ou xml) após a URL, ex: http://codepaste.net/pouviy?format=xml. Também possui suporte a RSS e ATOM para fornecer listas.

Todo o código fonte do site está disponível para revisão.

Pastie, um site semelhante, oferece o mesmo serviço mas de uma escolha muito maior de línguagens, incluindo Java, Ruby, C + +, Python, Perl, PHP, Pascal, YAML, entre outros.

Fonte: InfoQ

Uma discussão interessante no grupo de discussão DotNetArchitects, sobre vantagens e desvantagens do uso de ASP.Net MVC e C# ou Ruby e Rails, no link: http://groups.google.com/group/dotnetarchitects/browse_thread/thread/39ce51f8fd30a955?hl=pt&pli=1

Fonte: Twitter Giovanni Bassi

Muitas vezes um arquiteto é confundido com um desenvolvedor sênior ou projetista especialista. Um arquiteto, entretanto, não é um projetista especialista de uma tecnologia. O arquiteto de software é apenas outro papel, com outras atribuições e outras funçoes, conforme podemos observar dentro das escolas de renome de arquitetura de software no mundo, como por exemplo o SEI SAT .

Um arquiteto é um papel generalista. Um projetista é um especialista para um determinado domínio (ex: Java EE ou .NET). A figura abaixo, adaptada do trabalho de Gerrit Muller, explora esta dicotomia.

Fonte: Arkhi

Postado por Abel Avram, traduzido por Rony Barbosa em 13 Jul 2009 12:21 PM

Eric Nelson, um Desenvolvedor Evangelista da Microsoft e editor técnico da MSDN UK Flash, reuniu uma lista de 23 projetos abertos .NET, a maioria baseado em recomendações enviadas dos desenvolvedores Ingleses. Outros grandes projetos não foram inseridos na lista, enquanto contribuições da Microsoft incluem: ASP.NET MVC, DLR, IronRuby, IronPython, MEF.

Eric tentou incorporar apenas um framework de testes, um framework de mocking, etc. Embora existam mais de um. Sua lista contém os seguintes projetos:

1. [TEST] xUnit.net – Um dos vários frameworks de teste ótimo para auxilio de TDD.
2. [TEST] RhinoMocks mocking framework -Testes fáceis pelo fato de permitir o desenvolvedor criar implementações mock de objetos.
3. [TEST] White for automation of Windows applications – Condução programática de aplicações Windows.
4. [TEST] Gallio Automation Platform – Trabalha com muitos frameworks de teste, incluindo MSTeste, xUnit, Nunit e MbUnit.
5. [DATA] Fluent Nhibernate – Fluent Nhibernate leva você a escrever mapeamentos em código c# fortemente tipados.
6. [OOP] StructureMap Dependency Injection/Inversion of Control – Habilita uma redução de acoplamento entre classes e suas dependências.
7. [OOP] Managed Extensibility Framework – Faz a transição de aplicações que são compiladas estaticamente para dinamicamente compostas.
8. [APPFX] s#arp architecture for web applications – Base para desenvolvimento rápido de aplicações web usando ASP.NET MVC com Nhibernate.
9. [APPFX] OpenRasta REST based framework for building web applications – Simplifique expondo uma API baseada em REST para a sua aplicação.
10. [APPFX] CSLA.NET Application Framework – Um abrangente framework para desenvolvimento .NET.
11. [APPFX] Spring.NET Application Framework – Um abrangente framework para desenvolvimento de aplicações web.
12. [RUNTIME] Mono enables .NET on Linux and Mac – Use aquelas habilidades .NET intencionando Linux, BSD e OS X.
13. [UTIL] Sandcastle Help File Builder – Cria uma documentação no estilo do MSDN para assemblies .NET.
14. [HELPER] EasyHook for Windows API Hooking – Estenda código não interpretado (APIs) com código interpretado.
15. [HELPER] Json.NET for working with JSON formatted data – R/W usando o JsonReader e JsonWriter ou serialize seus objetos .NET com uma única chamada.
16. [HELPER] Excel Data Reader for Excel 97 to 2007 – Leia arquivos Excel diretamente em um dataset.
17. [HELPER] #SNMP Library – Uma interface API natural para encapsular funções SNMP.
18. [HELPER] DotNetZip Library  - Uma ótima biblioteca ZIP com algums exemplos.
19. [HELPER] Visio Automation Library  - Automate Visio para C#, Visual Basic e outros.
20. [HELPER] PHPExcel is not just about Excel! – PHP classes para r/w Excel 2007, PDF, HTML e outros.
21. [HELPER] Argotic Syndication Framework for RSS, Atom, OPML and more – Faça a leitura e escrita de conteúdo em vários formatos comuns facilmente.
22. [HELPER] NLog logging library – Escreva facilmente diagnóstico de trecho de código para sua aplicação.
23. A great directory of C# Open Source software – Um bom diretório de bibliotecas, frameworks e ferramentas.

Outros ótimos projetos enviados que não estão na lista final:

• Castle
• MvcContrib
• Subversion
• Nant
• log4net
• Lucene
• CruiseControl
• Paint.NET

Algumas contribuições substanciais da Microsoft sobre a licença MS-PL são:

• ASP.NET MVC Open Source
• .NET Dynamic Language Runtime (DLR)
• IronRuby
• IronPython
• Silverlight Toolkit
• Ajax Control Toolkit
• Managed Extensibility Framework (MEF)

MS-PL é uma licença aprovada OSI e caracterizada pelo GNU como uma licença de software livre que permite qualquer um ver o código fonte, modificá-lo e compartilhar as modificações com outros. Além disto, a licença não limita que o código rode apenar sobre Windows, abrindo possibilidades para portá-lo a outros sistemas operacionais. Dois exemplos são o Mono (.NET no Linux) e Moonlight (Silverlight no Linux). Um plug-in está sendo criado para MonoDevelop para usar ASP.NET MVC no Linux, Mac e OS X.

Fonte: InfoQ

Postado por Abel Avram, traduzido por André Dourado em 24 Jun 2009 02:26 PM

Muitos se perguntam por que a Microsoft está dando um tratamento diferenciado para o VB.NET comparado ao C#, por que desenvolvedores VB.NET recebem menos que desenvolvedores C# e se eles devem se preocupar com seu futuro ou não. Em um podcast, Lisa Feigenbaum, gerente de projetos no grupo de linguagens gerenciadas .NET, garante à comunidade VB.NET que o VB definitivamente tem futuro.

Lisa explicou porque VB.NET e C# tem tido uma percepção diferenciada: foi uma decisão estratégica da Microsoft em primeiro lugar. Microsoft não apenas quer duas linguagens com duas sintaxes diferentes rodando no CLR, mas eles quiseram que fossem diferentes em seus recursos, então as duas linguagens seguiram em diferentes caminhos no mundo .NET. Desde que a maioria da documentação relacionada saída da Microsoft contém exemplos em C# e menos exemplos em VB.NET, todos concluíram que o VB.NET é menos favorecido e possivelmente morrerá com o tempo, não tendo suporte suficiente.

De acordo com Lisa, no início a Microsoft tentou diferenciar as duas linguagens, implementando diferentes recursos em cada uma delas, mas muitas vezes clientes VB.NET solicitaram tem recursos disponíveis para o C#, enquanto clientes C# desejaram recursos disponíveis no VB.NET, portanto no final uma decisão foi tomada para manter ambas em sincronismo. Também, o número de desenvolvedores VB.NET é um poucco maior que os desenvolvedores C# e a Microsoft não matará o VB.NET porque não é do interesse deles fazer isso. Esse comprometimento foi reforçado quando dois times de arquitetos foram reunidos por 18 meses com o objetivo de co-desenvolver as linguagens.

Anders Hejlsberg, Arquiteto Chefe para o C#, supervisiona o desenvolvimento de ambas linguagens para garantir seu progresso. Após a decisão sobre alguns recursos a serem implementados para C# e VB.NET, os respectivos times de desenvolvimento são separados em ambientes distintos, para que possam desenhar a implementação dos recursos, de acordo com a sintaxe e regras gerais de cada linguagem. Este processo apresenta dois resultados: as linguagens mantém a adição dos mesmos conjuntos de recursos e as linguagens mantém sua personalidade e não necessariamente tentam copiar o modo que a outra é implementada. Isto garante que o VB.NET não será eventualmente absorvido pelo C#.

As linguagens estão rapidamente convergindo. No momento, as únicas aplicações que podem ser feitas em C# e não podem ser feitas em VB.NET são jogos XNA, porque não há templates de projetos para o VB.NET. Mas a Microsoft deseja encerrar completamente esse gap, de forma que as duas linguagens se tornem completamente iguais.

Os resultados do esforço conjunto serão vistos mais claramente na próxima versão do Visual Studio. VS foi inciado inicialmente em C, C++, mas o editor e compilador do VS 2010 conterá mais código gerenciado que antes, isto significa mais código C# e VB.NET. Nem o VS ou Office iniciaram tendo tanto código gerenciado do dia para a noite porque existe uma imensa quantidade de código valioso já escrito, mas códigos novos geralmente são códigos gerenciados.

O fato que alguns estudos mostram que desenvolvedores VB.NET são pagos de 10-15% menos que seus colegas desenvolvedores C#, pode ser decorrente do fato que a percepção sobre VB.NET ainda não mudou o bastante e mais tempo ainda é necessário para que se perceba que estas linguagens são iguais e são tratadas da mesma forma pela Microsoft.

Fonte: InfoQ

Postado por Marco Mendes para o Blog do Marcos Mendes
em 30 de Maio de 2009

No Budismo, o caminho do meio (madhyamā-pratipad, em sânscrito) é a prática de ensinamentos que nos afastem das vaidades, extremismos e nos guiem a uma busca por mais sabedoria, moralidade e raciocínio.

No mundo Java e .NET, o caminho do meio possui o mesmo conceito. Gostaria de compartilhar, neste contexto, uma interessante leitura sobre experiências de diversos arquitetos de software que guardam uma espantosa coincidência com as idéias e conceitos do caminho do meio.

Esta lições estão coletadas no excelente e sucinto livro 97 Things Every Software Architect Should Know, escritas por diversos arquitetos de todo o mundo e compiladas por Richard Monson-Haefel.

Dentro das 97 dicas presentes neste livro, gostaria de destacar três:

• Não coloque seu resumè a frente dos seus requisitos. Este pequeno texto discute porque bons arquitetos primeiro entendem o problema e o contexto de negócio antes de propor a tecnologia preferida do seu currículo. A lição é clara: não leve a sua tecnologia Java ou .NET preferida para o seu cliente antes de entender claramente o problema.




• Simplifique a complexidade essencial, diminua a complexidade acidental. A complexidade essencial diz respeito a complexidade inerente a um problema. A complexidade acidental diz respeito a efeitos colaterais introduzidos por escolha de tecnologias complexas e soluções estado da arte. Exemplos são o uso de EJBs, servidores como o BizTalk, servidores de transações distribuídas ou modelos complexos de orientação por objetos para problemas simples que não necessitam deste tipo de solução. A lição novamente é clara: não introduza complexidade acidental para aprender uma nova tecnologia. É responsabilidade do arquiteto gerir bem o dinheiro do projeto, da sua empresa e do seu cliente. Não brinque com o dinheiro alheio por vaidade.




• Arquitetura é sobre equilíbrio. A arquitetura deve equilibrar aspectos técnicos e aspectos de negócio (condutores de negócio). “Arquitetos Java e .NET” que se esquecem de olhar para o negócio estão violando o caminho do meio. Estão buscando apenas um meio de satisafazer seus egos no uso de soluções “elegantes” e criar novos desafios técnicos que apenas eles precisam.

Um “arquiteto Java” e um “arquiteto .NET”, portanto, irá se tornar um melhor arquiteto se não ficar cego pelas palavras “Java” e “.NET” e colocar no seu cardápio porções de liderança técnica e práticas de alinhamento ao negócio.

Fonte: Blog do Marco Mendes