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

Jeff Sutherland, um dos criadores do Scrum, nesse vídeo cobre alguns tópicos relativos a auto-organização dos times Scrum.

Palestra realizada no Google Tech Talk, em 4 de Setembro de 2008.

Uma twitada do @andrediasbr nos mostra que não é só a forma de construir software que está mudando, a forma de atrair bons profissionais também evoluiu.

A empresa Webgoal colocou em seu site, na área de recrutamento um texto do perfil de profissionais que está a procura:

Estamos contratando desenvolvedores que são independentes de linguagem, que saibam trabalhar em par e não precisem de um gerente!

Tem que saber planejar, estimar, analisar, modelar e desenvolver software em equipe. É um diferencial ser formado em ciência ou engenharia da computação. Mas se você for muito bom mesmo, isso não importa.

Você precisa ter experiência com a maior parte desta sopa de letrinhas: MVC, UML, XML, HTML, CSS, JS, PHP, C#, JAVA, RUBY, TDD, BDD, SCRUM e XP.

Você precisa ter muita responsabilidade, disciplina e pró-atividade, pois aqui você será livre. Gostamos de trabalhadores do conhecimento. Esse é o pré-requisito mais importante.

Você vai ter que trabalhar 40 horas por semana. Por favor, não insista. Você precisa ter um tempo para você, sua família e amigos.

Além dos benefícios costumeiros oferecidos pelo mercado, ainda temos plano de carreira, plano de formação profissional, participação nos lucros obtidos com os nossos produtos e um ambiente de trabalho diferenciado e motivador.

Quanto estamos pagando? Isso só depende de você. Nossa escala de salários (aqui é CLT) para profissionais raros vai de R$ 1.000,00 (estagiário) a R$ 7.000,00 (engenheiro de software).

Você é a pessoa certa? Se sim, preencha o formuláro abaixo e envie-nos seu currículo.

É quase um manifesto ao desenvolvedor ágil. Parabéns pela evolução na forma de contratar.

Fonte: Twitter @andrediasbr

O ranking da TIOBE é atualizado mensalmente e mede a popularidade das linguagens de programação, utilizando como base os mecanismos de busca mais utilizados (Google, Msn, Yahoo) além do Youtube. Este ranking é bastante utilizado, para demonstrar o crescimento ou não de determinada linguagem.

Position Oct 2009	Position Oct 2008	Delta in Position	Language	Ratings Oct 2009	Delta Oct 2008	Status
1	1		Java	18.718%	-2.23%	A
2	2		C	16.891%	+1.33%	A
3	5		PHP	10.390%	+1.78%	A
4	3		C++	9.911%	-1.04%	A
5	4		(Visual) Basic	8.729%	-1.08%	A
6	8		C#	4.433%	+0.67%	A
7	6		Python	3.914%	-0.65%	A
8	7		Perl	3.776%	-0.64%	A
9	11		JavaScript	3.033%	+0.36%	A
10	10		Ruby	2.458%	-0.40%	A
11	9		Delphi	2.140%	-1.15%	A
12	13		PL/SQL	1.020%	0.00%	A
13	49		Objective-C	0.902%	+0.82%	A–
14	14		SAS	0.805%	+0.21%	A
15	16		Pascal	0.669%	+0.15%	A-
16	20		ABAP	0.661%	+0.22%	A-
17	19		Lisp/Scheme	0.605%	+0.12%	B
18	22		MATLAB	0.577%	+0.17%	B
19	12		D	0.570%	-0.76%	B
20	15		Lua	0.527%	-0.02%	B

O ranking completo pode ser encontrado no link: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

No dia 16 de outubro (sexta-feira) às 08:00 será realizado o Workshop Agile Software Development with Extreme Programming no CESUPA, um workshop bem dinâmico e com muitas práticas para experimentar os benefícios do XP no desenvolvimento de software de qualidade!

O Workshop será conduzido por Manoel Pimentel e Paulo Igor. Nesse treinamento o participante será imerso numa visão pragmática dos valores, princípios e práticas ágeis da metodologia Extreme Programming (XP), através de muitas dinâmicas e compartilhamento de exemplos reais, mostrando como a adoção da XP, em equipes de desenvolvimento, pode gerar software de forma mais ágil e com alta qualidade para as organizações e clientes que realmente valorizam seus investimentos em projetos de software.

Nesse workshop o participante também exercitará a aplicação real dos valores do XP através de algumas sessões de Coding Dojo, onde será possível praticar e melhorar as técnicas de programação, construindo em conjunto com outras pessoas uma aplicação, compartilhando experiências e exercitando boas práticas de programação orientadas a filosofia do XP.

O número de vagas é limitado, se inscreva no site http://www.tasafo.org/wsxp_inscricao.php

A ementa do workshop encontra-se logo acima do formulário de inscrição.

Um post no blog Débito Técnico do Rodrigo Yoshima, onde ele faz uma relação ao que matou o RUP pode matar o Agile.

…
O que vocês devem estar se perguntando é: O que matou o RUP e pode matar o Agile? Como eu falei, eu temo pelo movimento Agile. Assim como foi em 2003, em 2009 eu ví o primeiro pseudo-especialista Agile falando absurdos – violando valores. A partir do momento que eu vejo a comunidade Agile discutindo e dando importância demais a post-its, quadro de tarefas e cartinhas de planning poker, eu temo pelo movimento Agile. Quando eu vejo a comunidade Agile buscando certificações, preocupados em como casar Agile com CMMI ou como adaptar Agile à contratos de escopo fechado, eu temo pelo movimento Agile. Sempre que eu vejo isso no mundo Agile, me transporto a 10 anos atrás e me lembro das discussões sobre templates de casos de uso, definições de padrões de modelagem UML, pensamento linear, check-lists de artefatos, uso incorreto de ferramentas, falta de compreensão sobre fases e o pior de todos: o departamento que cuida dos processos de desenvolvimento. Resumindo, quando vejo esse mind-set de besteirols e libertinagens Agile, eu me lembro do mind-set burro e burocrático que contaminou o RUP.

O que matou o RUP foi a falta de entendimento, e isso é o que vai matar o Agile. Lean é o próximo da fila. Escreva aí: em 5 anos, dependendo dos ventos da economia e do clima empresarial, muitos vão estar criticando Agile do mesmo modo que hoje criticam o RUP, sem autoridade de causa. Tudo vai depender do mind-set vigente no momento. Tudo depende do mind-set: se você der o Scrum e XP para um “tradicionalista” ele não vai mudar seu mind-set, mas sim adaptar o Scrum e o XP às suas “crenças”. Se você der o RUP para um pragmático, ele também não muda o seu mind-set, mas sim, adapta o RUP à sua realidade. Você pode decidir o seu mind-set: ou você realmente acredita nos 4 valores e 12 princípios ágeis e adota este estilo, ou você se enche de penduricalhos ágeis só para ficar na modinha.
…

O post completo pode ser encontrado em: http://blog.aspercom.com.br/2009/09/29/o-que-matou-o-rup-pode-matar-o-agile/

Fonte: Débito Técnico

Fonte: Scrum Log – Jeff Sutherland

Post do Fábio Akita, onde ele traduz a palestra entitulada “O Visual Studio estraga nossas mentes?“, apresentada no NYC .NET Developer’s Group, em 20 de Outubro de 2005 por Charles Petzold. Concordo em grande parte com o que foi colocado:

De tempos em tempos alguém me pergunta algo do tipo “Que IDE você usa para programar em Ruby?” E todos ficam surpresos ou frustrados quando eu digo “Nenhum, apenas um editor de textos competente.” Parece que a maioria dos programadores de Visual Basic, Delphi, Java, C#, VB.NET, simplesmente não conseguem sair do dogma dos IDEs com IntelliSense.

Eu, felizmente, comecei a programar dBase numa era onde o máximo em editor de textos era o Wordstar. No DOS eu usei EDLIN e depois o Edit que vinha nos DOS acho que 5.0. Quando fui programador Clipper no começo da década de 90, meu editor favorito era o Norton Editor. Somado a ferramentas como Sidekick, eu tinha a estação de desenvolvimento mais poderosa que se poderia querer: um editor de textos e só.

Quando o Java surgiu, um IDE com capacidades de auto-complete eram obrigatórias. Em .NET a mesma coisa, e pelas mesmas razões. Aqui eu traduzo a palestra entitulada O Visual Studio estraga nossas mentes?, apresentada no NYC .NET Developer’s Group, em 20 de Outubro de 2005 por Charles Petzold. Ele faz uma longa análise dos fundamentos de porque um programador viciado nos dogmas impostos pelo Visual Studio está se tornando um programador ruim.

Atualmente, eu programo apenas Ruby (e outras coisas como Javascript de vez em quando) apenas no Textmate, um competente editor de textos, reminiscente de inspirações em Emacs e Vim, outros dois excelentes editores. E não sinto falta de Eclipses, Netbeans ou qualquer coisa desse tipo e, obviamente, nenhuma falta do Visual Studio. Ah sim, precisar de auto-complete só mostra uma coisa: que as APIs estão sendo muito porcamente desenhadas ultimamente, tornando-as ridiculamente longas!

Recomendo ler o artigo inteiro, pois só traduzi as partes relevantes ao meu ponto. Vamos à tradução:

PS: Vale a pena descrever o paradoxo: não dá para efetivamente ser produtivo em .NET sem Visual Studio, em Java sem Eclipse/Netbeans/etc ou ObjC sem XCode. Isso é um fato. Na prática mesmo, a solução não é fazer C# em Notepad. Esse é o ponto a se pensar

O post completo pode ser encontrado no link: http://akitaonrails.com/2009/09/17/tradu–o-os-problemas-do-pensamento-do-visual-studio-e-outras-ides

Mike Cohn elaborou uma interessante idéia da qual concordo, mas que pode parecer uma heresia para muitos agilistas: Agile tem tudo a ver com micro-gerenciamento!!!

Sim, isso mesmo, provavelmente alguns devem ter iniciado uma fogueira para queimar os excelentes livros do Mike Cohn sobre gestão e estimativas ágeis em projetos e sobre user stories. Mas antes de riscar o fósforo deixe a idéia ficar mais clara .

Diversas práticas básicas dentro de métodos ágeis estão lá para suportar o micro-gerenciamento das pessoas. Exemplos:

- O Daily Stand-up Meeting (Reunião diária de 15 minutos em pé) é um micro-gerenciamento diário do planejamento da iteração. Ele garante que todos estão fazendo ou farão aquilo que deveriam.

- A Integração Contínua é colocada para que, no instante em que um desenvolvedor cometa um erro e quebre um build, todos fiquem sabendo rapidamente.

- A programação em pares garante que os desenvolvedores não percam o foco, não façam goldplating e que limpem e refatorem continuamente o código.

Mas quem faz esse micro-gerenciamento todo? Aí vem o ponto importante: a equipe faz um auto-microgerenciamento! Isso é bem diferente de um gerente micro-gerenciar. Quando a equipe faz seu próprio micro-gerenciamento ela só tem benefícios e realiza o nirvana da auto-organização.

Fonte: José Papo Weblog

Postado por Mike Bria, traduzido por Paulo Henrique em 09 Set 2009 08:55 AM

Há debates incessantes sobre se a adoção ágil é melhor realizada de uma forma mais gradual ou com uma abordagem "tudo-ou-nada". Johanna Rothman diz que é necessário realizar as duas abordagens: os projetos devem mergulhar nela, enquanto as organizações devem levá-la gradualmente.

Nos 2 últimos posts, Plunge In (For Projects) e Small Steps Are Good, Be Careful What You Call Them, Johanna postula que as pessoas precisam mergulhar de cabeça na adoção de abordagens ágeis no nível do projeto. Em essência, ela toma uma linha mais rígida do que fazer as coisas como trabalhar em iterações “timeboxed” ou fazer integração contínua, mesmo que esteja melhorando a sua situação, não significa que você está fazendo "ágil". E ainda assim você está se preparando para o fracasso se você chamar isso de ágil:

…se você chamar algo ágil, por favor, torne-o ágil. Se você mergulhar nele, você ainda não fez o compromisso. Se você variar seu “timebox” dependendo se você terminar o trabalho no “timebox”, isso não é ágil; é desenvolvimento incremental. Você pode dizer: "Nós estamos experimentando com o desenvolvimento incremental. Nós escolhemos variar o tamanho do “timebox” para que possamos começar a prática do conceito de “done”. Talvez depois de praticá-lo por um tempo, nós vamos corrigir os nossos timeboxes e ver como é que funciona".

Isso é perfeitamente razoável. Convido você a fazer isso, se você ainda não experimentou desenvolvimento incremental ainda. Mas não o chame ágil. Pois, não é.

Logo depois, Rothman apresentou um terceiro postulado que, em última análise sugere o oposto quando se trata de níveis organizacionais de adoção ágil. Ela sugere que os gerentes adotem uma abordagem mais gradual em relação à evolução das estruturas administrativas em toda a organização:

Migrar uma organização para um conceito ágil é um problema não-trivial. A etapa 0 é o projeto. O primeiro passo é a portfólio de projetos. Em seguida, vem o trabalho realmente duro: os sistemas de recursos humanos são o próximo passo. Uma vez que você migrou os sistemas de recursos humanos de volta para ajudar os funcionários, agora você pode atacar os sistemas orçamentários. (Um dos meus clientes está tentando fazer os sistemas orçamentários em primeiro lugar, e que não está funcionando. Pode haver alguns prós e contras com os sistemas de recursos humanos e orçamentários).

Gerentes, mergulhe agilmente para os sistemas de gestão, desde que você pegue uma parte coerente e comprometa-se de forma ágil ou lean para essa parte. Não é bom mergulhar em um determinado projeto, comprometer-se agilmente para um projeto, se isso é certo para você. E, comprometa-se a aprender sobre gerenciamento ágil e lean.

Em essência, Rothman diz sobre esta pequena série de postulados que fazer bem de forma ágil requer um nível de disciplina que nem todos os projetos estão preparados. Escolha quais projetos estão prontos, e migre-os totalmente, mas, não se preocupe com a transição de todos os projetos ou toda a organização de uma só vez, pense ‘gradual’ quando se trata disso. O que você acha?

Fonte: InfoQ