A comunidade .NET Architects convida a todos os interessados a participarem do nosso primeiro evento presencial, tendo em vista a missão do grupo:
"Desenvolver e compartilhar as melhores práticas de arquitetura e engenharia de software na plataforma .Net"
Qual a idéia do evento:
- Temas apresentados por membros ativos do grupo e MVP's;
- Apresentações focadas na experiência dos palestrantes, e não somente na tecnologia;
- Interação com a comunidade;
- Sorteio de brindes (DVDs VSTS, Livros, Camisetas, entre outros);
- Temas focados em arquitetura de soluções;
- Oportunidade de interagir com outros arquitetos de software e interessados no assunto.
Temas a serem apresentados: Mais informações: http://www.dotnetarchitects.net/page/NET-Architects-Day-2009.aspx
Abraços!
| A sopa de letrinhas ao lado representa a maioria das abordagens que as empresas “inovadoras” estão fazendo. Criam um site, publicam seus vídeos no youtube, criam uma comunidade no orkut e facebook, jogam algumas frases no twitter, enviam SMS para os clientes e um ótimo e-mail marketing finaliza a lista básica.
E na prática esta é a nova abordagem Web da empresa inovadora, conversando com seu público através deste incrível meio que é a Web… Mas a grande questão é: adianta estar lá e não saber o que falar? O que usar e de que forma usar para dar certo? | Site YouTube Orkut Facebook MySpace
Twitter Live Messenger Bots PodCast SMS
E-mail Marketing… |
Não dá pra fingir que sabe: passe para um especialista
Estratégias, estudos e recomendações baseadas em estudos extensos existem sobre marketing online, interatividade, etc. Se você tem alguém especializado assim na sua empresa, ou se você é especializado neste tipo de mídia, fique a vontade para trabalhar com isto. Caso contrário, chame um especialista. Não existe nada pior que ver as pessoas reclamando que as abordagens na web da empresa X não funcionam e ninguém sabe o porquê.
Utilize as estratégias, baseie-se nos estudos, leia os cases de sucesso e usufra das recomendações que já estão por aí.
Foco no público
Imagine a seguinte situação: você vai a uma palestra sobre Veículos de grande porte, e o palestrante começa a falar sobre bicicletas infantis…
Tirando a brincadeira, na web existe um público diferente. Se esse público acessa o twitter ou YouTube então, pior ainda.
Não tente falar sobre campanhas da terceira idade no twitter. Muito provavelmente quem está lendo ainda não tem 4 décadas de vida (e se tiver não está pensando nisso).
Interatividade: se não tiver isso pra que então?
Nunca se esqueça de que a grande vantagem da web é a comunicação com o cliente. E hoje é muito comum ouvir a opinião do cliente, que está fazendo questão de falar mal e - por mais impressionante que seja - reconhecer quando o produto é bom.
Se só você e sua empresa podem falar, vamos pro rádio (ou então podcasts!)
Objetividade, honestidade e… cuidado com os comentários
Os costumes na web mudaram, assim como a percepção dos usuários. Fazer propagandas o tempo todo, com comentários infundados sobre alguns produtos ou serviços pode ser o fim da sua marca nas mídias sociais. E o pior: os visitantes vão comentar.
Alias, saber interpretar os comentários faz toda a diferença. E muito cuidado com o retorno. Isso pode se alastrar em questões de minutos.
Conclusão
Os tempos mudaram e precisamos entrar corretamente nesta nova era.
Na última década o investimento publicitário em mídia no mundo cresceu cerca de 30%, enquanto os jornais perderam 8% da participação no bolo. Será que isso não quer dizer alguma coisa?
Como este campo ainda é muito novo, uma tentativa “desesperada” de entrar neste mercado pode acabar por comprometer qualquer campanha ou intenção futura no meio digital. Portanto cuidado!
Há muito tempo escrevi um post falando da minha visão sobre 3 pontos interessantes em relação a debugging. E neste novo post eu gostaria de destacar o terceiro item, “Desenvolvimento Pró-ativo”:
“Como Edsger Dijkstra citou, se debug é o processo para remover os bugs, programar é o processo para criá-los. Partindo deste pensamento, por que não evitar os bugs? Por que não programamos pensando em evitar bugs, além de resolver os problemas do negócio? Muitos destes bugs ocorrem por falta de um simples if (obj != null), por incrível que pareça!”
E apesar de ter publicado o post em novembro de 2007, este problema parece ser algo “normal” em toda fase de desenvolvimento de um projeto. E já que não conseguimos evitar bugs através de desenvolvimento pró-ativo, temos então que utilizar ferramentas que minimizem a possibilidade destes erros.
Testes – Caixa Branca
Existem algumas técnicas de testes que são extremamente importantes, mas para o contexto deste post temos que entender apenas a técnica da caixa branca.
Segundo o wikipedia, “Teste de caixa-branca é uma técnica de teste que usa a perspectiva interna do sistema para modelar os casos de teste. No teste de software, a perspectiva interna significa basicamente o código fonte. No teste de hardware, cada nó de um circuito pode ser testado.
Difere do teste de caixa-preta, em que a perspectiva interna do sistema é desconsiderada, sendo testadas e mensuradas somente as interfaces do sistema. Entretanto, ambas as técnicas podem ser usadas em conjunto, no que é chamado teste de caixa-cinza. Dessa forma, o teste é modelado conhecendo-se a estrutura interna do sistema, mas a execução ignora esse aspecto, como na caixa-preta.”
Basicamente o teste da caixa branca consiste em testar a sua implementação, não interessa em qual fase do desenvolvimento.
Porém, para aplicar um teste de caixa branca adequado, temos que utilizar algumas técnicas para identificar possíveis casos de testes para aquela código em específico. E é aqui que se encaixa o Pex, da Microsoft Research.
Pex – Automated White box Testing for .NET
Pex nada mais é que um “gerador automático de entrada para testes”.
Segundo sua documentação, teste unitário está se tornando muito popular nos últimos anos. E isso se confirma pela abordagem da Microsoft em seus projetos, como ASP.NET MVC por exemplo.
O conceito básico para o Pex envolve o conceito de Teste Unitário Parametrizado. Este tipo de teste é muito parecido com o teste unitário comum, porém a única diferença é que ao invés de especificar valores fixos para o teste, é possível determinar uma série de valores e obter o resultado geral do teste de acordo com cada valor informado na entrada.
O funcionamento do Pex é extremente simples.
Primeiro passo é criar o documento de testes relacionado ao Pex. Para isto, abra a classe que deseja testar e clique com o botão direito, selecionando a opção Pex > Create Parameterized Unit Test Stubs. Isto irá criar uma classe de testes que cobrirá todos os testes de sua classe através de teste unitário parametrizado.
Com o arquivo de teste criado, basta clicar – ainda na classe que será testada – em Run Pex, e analisar o resultado dos seus testes.
Você poderá notar, entre outras coisas, todos os parâmetro de entrada e o resultado da execução do seu método:
Conclusão
Este tipo de ferramenta é extramemente útil em qualquer contexto de desenvolvimento. Reduzir tempo na construção dos testes, ao mesmo tempo que se mantém a garantia do software nos permite centralizar os esforços ao desenvolvimento da lógica do negócio.
Na minha opinião, o Pex deve ser aplicado a qualquer fluxo de desenvolvimento, seja em projetos, fábricas de codificação, ou qualquer outro ambiente de trabalho.
Acesse o link e conheça mais sobre todo o potencial que o Pex pode oferecer.
Referências
http://research.microsoft.com/en-us/projects/Pex/
http://research.microsoft.com/en-us/projects/pex/pextutorial.pdf
Abraços!