Oportunidade Nimbus: Desenvolvedor de soluções na plataforma Microsoft .NET

A Sr. Nimbus é uma empresa de pequeno porte especializada em consultoria e treinamento na plataforma de desenvolvimento Microsoft. Um de nossos objetivos é auxiliar nossos clientes a atingirem o seu potencial máximo no uso das ferramentas desta plataforma. Para isto, temos que ter uma equipe bem preparada e experiente. E um de nossos desejos é conseguir este tipo de profissional através de nossas “categorias de base”: realizar a preparação e orientação de profissionais promissores, mas ainda sem grande contato com o mercado.

Nosso processo de trabalho emprega as seguintes disciplinas: 

• Framework para gerenciamento de projetos: SCRUM (http://www.scrum.org/scrumguides/);
• Automação do ciclo de desenvolvimento de software: Microsoft Team Foundation Server 2010 (http://msdn.microsoft.com/en-us/library/fda2bad5.aspx);
• Desenvolvimento de aplicação para o Windows Azure (http://www.microsoft.com/windowsazure/)
• Desenvolvimento ASP.NET;
• TDD – Test-Driven Development (http://www.agiledata.org/essays/tdd.html);
• Microsoft Visual Studio 2010 como ambiente de desenvolvimento.

Estamos com uma vaga aberta na área de desenvolvimento de soluções. Os pré-requisitos da vaga são:

• Experiência em desenvolvimento C#.
• Experiência em desenvolvimento ASP.NET.

Nosso objetivo para este profissional é a formação de um consultor especializado nas principais tecnologias das plataformas de desenvolmimento Microsoft: .NET Framework, Windows Azure e SharePoint. A formação envolverá cursos, self-study, shadowing de nossos consultores sêniores nos seus atendimentos, além de, é claro, muita “mão-na-massa”.

Se você se interessou, mande seu currículo para gilberto.uchoa@srnimbus.com.br. 
Abraços
 
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br

Não sofra depois, aperte o cinto logo no começo...

Com o passar do tempo em que você fica dentro de um único cliente, e quanto mais entende do negócio, sua importância aumenta exponencialmente dentro do projeto ou na integração desses projetos.

Por um lado essa situação é super interessante, pois é criado um elo de confiança, um relacionamento duradouro entre as empresas e, muito provavelmente, você melhore a efetividade do seu trabalho e dos resultados. Por outro lado, existe uma boa chance de que você acabe se tornando um ponto focal para solução de problemas e novas demandas, que vai impactar diretamente o gerenciamento do seu trabalho, pois o número de interrupções cresce demais e aquele trabalho técnico isolado fim a fim (que tanto gostamos de fazer), acaba sendo atrapalhado.


Particularmente eu estou vivendo essa situação que é muito gratificante e, como sempre, aprendendo demais com novos trabalhos, então resolvi compartilhar um aprendizado com vocês...


Estou trabalhando com o CRM 4.0 da Microsoft e carregando uma série de dados (oriundos de fontes diversas) utilizando como canal de entrada os web services publicados pelo produto. Recentemente codifiquei tudo o que precisava para importar uma entidade específica e larguei a rotina em background no servidor, fazendo a importação dos dados para essa entidade, que terá alguns milhões de registros.


Em um primeiro momento estávamos com uma média de 36.000 registros por hora, o que me dizia que em dez horas eu teria importado aproximadamente 360.000 registros. Como a rotina de inserção faz algumas chamadas de validação, para evitar - por exemplo - registros com um campo específico duplicado, essas rotinas ficariam mais pesadas com o tempo (pois aumentaria o volume de registros para validação dentro do CRM) e imaginei que o processamento efetivamente iria demorar mais do que um número X de dias estimados.


Com as inserções em andamento, o que eu previa aconteceu. Com o passar do tempo o número de registros importados por hora caiu, fazendo que a importação passasse a demorar mais tempo. Eu, com outras demandas (sempre urgentes e para ontem - vide parênteses abaixo) pensei: larga esse trem lá em background enquanto eu toco as outras tarefas, está ficando cada vez mais lento, mas me parece ser o comportamento normal.


Abre parênteses: ODEIO quando as pessoas que insistem em falar "ISSO É PARA ONTEM". Por acaso você têm uma máquina do tempo? Vai usar o delorean e viajar para o passado e fazer a entrega? Então animal da cauda, que tal parar de irritar as pessoas falando isso e discutir estratégias e novos prazos para você conseguir o que quer? Se era para ontem, ou não foi comunicado, planejado ou alguém cometeu um erro de estimativa, mas não importa, entenda o que aconteceu e foque na solução. Fecha parênteses.


Nesse meio tempo a importação ficou cada vez mais lenta, chegando a ficar quase 10 vezes mais devagar que a velocidade original. Achei bem estranho os números que estava vendo, mas sem tempo de analisar se o comportamento (e bem ou mal estava rodando), dei prioridade para outras tarefas, até esse fim de semana, onde o processo insistiu em sofrer com exceções de timeout do CRM.


Sem ter para onde correr, fui em busca da raiz o problema: VS debugger, profiler, tudo rodando direitinho e sabe o que eu descobri? Um índice fundamental para minha pesquisa no SQL Server não estava criado na tabela que representa a entidade! Pelo padrão de implementação que estamos utilizando, este índice já deveria ter sido criado, mas na falta dele as consultas acabavam em um lindo table scan.


Criado o índice para suportar a consulta, voltamos à taxa de importação que eu via no início do processamento (quando um table scan era baratinho, baratinho). Tudo resolvido, voltei para as outras atividades com essa experiência me cutucando (doida para chegar ao blog).


O interessante é que durante o fim de semana mandei um e-mail para um dos envolvidos no projeto, falando sobre o problema de timeout, e ontem fomos conversar quando ele disse: "Uma das ações que vou fazer é aumentar o timeout.". Sabe qual foi minha resposta: "Não, eu quero que você coloque o valor mais baixo possível para o timeout!" (foi curioso a cara de espanto do meu amigo).


Entendeu o motivo da minha requisição? Espero que sim...



A lição


Trabalhe (principalmente desenvolva) sempre com os menores limites possíveis, isto é, seja o mais restritivo possível nos tempos de resposta.


Passamos uma semana com uma importação rendendo pouco, muito pouco, mas como a coisa estava funcionando e rodando em background, eu priorizei outras atividades. Quando a tarefa realmente parou, eu precisei de menos de uma hora para corrigir o problema e voltar com uma importação dez vezes mais rápida. Acabei adiando o fim da importação em alguns dias por não ter gastado uma hora (OK, não tinha como adivinhar que seria somente uma horinha) para ver se a demora da importação era natural.


No que toca o CRM, se o timeout desde o início estivesse sido colocado bem baixo, o problema teria acontecido antes e com certeza hoje eu já estaria com todos os milhões de registros importados. Se pensarmos no desenvolvimento de novas soluções, é mais fácil você trabalhar com massas de dados e distribuições de recursos menores no desenvolvimento do que na produção. Aí talvez passe por aquele conhecido problema: "nossa, no desenvolvimento essa tarefa é tão rápida".


Então se no desenvolvimento você restringir bastante os seus timeouts (dos testes de unidade, acesso a dados - SQLConnection e SQLCommands -, chamadas a web services, etc.) provavelmente irá encontrar e resolver mais cedo alguns problemas que te assombrariam em produção. A partir de agora vou apertar o cinto logo no começo!



Melhor dificultar a coisa na sua máquina e resolver mais problemas, do que assistir de camarote quando, em produção, estiverem milhares de usuários acompanhando sua aplicação falhar... Pense nisso!


[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
http://www.srnimbus.com.br/

Evento em Brasília - ECODevelopers

Não sei se o pessoal anda antenado, mas teremos em Brasília o ECO Developers, um evento organizado por grupos de usuário e que toca um tema mais do que atual, o desenvolvimento sustentável.

Quer participar? Acesse o site: http://ecodevelopers.brasildotnet.net/.

[]s
Luciano Caixeta Moreira - {Luti}
Chief Innovation Officer
Sr. Nimbus Serviços em Tecnologia Ltda
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm

Testes de unidade, Azure e confiabilidade

Eu sou um grande fã dos testes de unidade, e mesmo não sendo um profundo estudioso do assunto testes, minha vida como desenvolvedor passou por uma transformação depois que eu comecei a trabalhar com eles, hoje eu não vivo sem.

Para ilustrar como os testes me ajudam, vou descrever um pouco do que eu fiz recentemente e, quem sabe, você também vai se sentir compelido a adotar essa boa prática de programação.

Primeiro eu codifiquei um wrapper para uma classe do projeto StorageClient que vem junto com o SDK do Azure e depois, para garantir que tudo irá funcionar corretamente, eu escrevi um teste que tentava criar uma série de containers passando com parâmetros os nomes mais esdrúxulos, conforme vocês podem ver abaixo:

Assert.IsTrue(ger.CriaContainer(@"ML:K()*_%^%$#@!@$#%^GBDF HGDSFKhf hdf kjh"));
Assert.IsTrue(ger.CriaContainer(@"~!#anjnd_)(* 8923849790>""?><>MarshalByRefObjectAssert.IsTrue(ger.CriaContainer(@"|{})_(*()*&h12h8934njkhf1"));
Assert.IsTrue(ger.CriaContainer(@"~!#anjnd_)(* 8923849790>"<>MarshalByRefObjectAssert.IsTrue(ger.CriaContainer(@"[]@#$|\\\skj382oflkuy"));
Assert.IsTrue(ger.CriaContainer(@"~s 092k3 jk3098 \\[hshsh"));

O método CriaContainer tenta limpar os nomes informados, deixando somente caracteres válidos. Porém eu somente comecei a escrever o método de limpeza do nome depois que meu teste estava pronto. O que eu fazia então...

while (ExecutaTeste() != tudoOk){
Luti_EscreveDireitoFuncaoLimpeza();
}

Enquanto o meu teste não passava todinho (o local storage do Azure gerava uma Exceção), eu continuava melhorando o método de limpeza. Depois de algumas iterações desse loop, o teste mostrou aquele check verdinho, tudo 100%.

Feito esse e mais outros testes, todos executando com sucesso, resolvi testar meu código diretamente contra a nuvem. Alterei o App.Config do meu projeto de testes para usar minha conta do Azure e executei a bateria com 10 testes: Verde, Verde, Verde, Verde, VERMELHO!

Uai, estava tudo certo?! Olha daqui, olha dali, vejo o problema. O armazenamento local permite que eu crie um container com o nome parecido com "empresa---xxx". O problema é que se olharmos a documentação, veremos "Every dash (-) character must be immediately preceded and followed by a letter or number".Ugh.

Resultado: o ambiente de desenvolvimento local não checa essa regra.
Sabe quando eu acho que iria encontrar um erro desse tipo se não fossem pelos testes, provavelmente em produção!!!

Depois disso alterei meu código para refletir os requisitos do Azure, re-executei os testes de unidade e tudo verde. Lindo.

Mas a coisa não termina por aí não. Depois de concluído os testes, resolvi baixar e instalar o CTP de Março (ainda estava com o de Janeiro). Instalei tudinho e adivinha qual foi a primeira coisa que eu fiz? Executei novamente minha bateria de testes... Tudo certo, então até que me provem o contrário, a instalação foi um sucesso.

Qual o meu sentimento no fim das contas? Eu estou confiando bastante no meu código e, toda vez que houver alguma alteração eu não vou precisar ficar 45 minutos para testar se houve alguma mudança que me prejudica, basta eu executar meus testes novamente que em alguns segundos eu saberei a resposta.

Gostou?

[]s
Luciano Caixeta Moreira
luciano.moreira@srnimbus.com.br
luticm79@hotmail.com