This is a test post sent by Blogo in order to generate a preview template. It should be deleted shortly.
parece chover no molhado, mas eu continuo me impressionando com o avanço do silverlight. o time de scott guthrie continua a surpreender. agora com o silverlight 4 - versão beta anunciada hoje no PDC.
se com o silverlight 3, ele começou a se tornar uma boa opção para business applications (aplicações de negócios), a versão 4 vem para consolidar isto.
entre as novidades disponíveis nesta versão beta estão: suporte a impressão, mais de 60 controles de form customizáveis, total compatibilidade de código que pode ser rodado sem nenhuma alteração em silverlight ou desktop, suporte ao google chrome, off-line DRM, suporte ao toast notification (aquela janelinha que sobe da task bar), possibilidade de ler e escrever nas pasta mydocuments, my music and my videos, interação com office, acesso através de COM a devices, como por exemplo leitores de cartão USB e a possibilidade de requisitar ao usuário acesso fora da "sandbox".
como podem notar a lista não é pequena. e está é só a parte que me interessou. há muito mais do que isto.
por isto fico impressionado com o scott e seu time. o silverlight 3 foi recém lançado e os caras conseguem vir com uma nova versão beta que não é apenas mais do mesmo. que acrescenta funcionalidades bem interessantes para que usá-lo para desenvolver aplicações de negócios.
não tenho como não instalar.
[]s
cheguei a um link bem interessante através de um tweet do kent beck. o post fala sobre como e por que aprender a ler o código de outras pessoas.
ele dá diversas dicas de como começar e o que fazer quando nos deparamos com código de outras pessoas que talvez nem estejam mais na empresa e precisamos adicionar uma funcionalidade ou corrigir um bug.
mas, um dos pontos que me chamou a atenção é quando ele fala sobre não odiarmos o código. ele traz atenção uma falha comum entre nós desenvolvedores, que é acharmos que o nosso código é melhor ou poderia ser melhor que o dele.
“You can get sucked into hating the code, merely because it is not yours. Software people tend to be equipped with ample egos, and other people’s code can offend. But realize, their working code is better than your imagined code, because their working code exists right now. So put your ego aside and learn the code in front of you” – design by gravity (o grifo é dele)
depois ele faz um alerta que pode nos ajudar também ao fazermos reviews em códigos de outros:
“the folks who built it the first time had a model for it, and it made sense to them. Respect them enough to look for that model. I will concede some peoples’ minds work in strange ways.” – design by gravity (o grifo é dele)
e mesmo que já tenhamos o nosso ego sob controle, vale a pena ler para ver as outras dicas.
[]s
a boa notícia é que o silverlight 3 está incluído no vs2010 beta 2. no beta 1 você até conseguia usar o silverlight 3, mas tinha que fazer muitas configurações na mão.
agora, após instalar o vs2010 beta 2 você já tem o SDK e a versão mais recente do silverlight 3 tools. quer dizer, já pode sair desenvolvendo.
o que não está incluído: o silverlight toolkit. este também tem uma versão mais nova, a de outubro. esta versão é compatível com o vs2010 e pode ser baixada aqui, ou se você quiser saber mais detalhes.
o .net ria services também não faz parte da instalação do vs2010. e ainda não existe uma versão que o suporte. dentro em breve deveremos ter mais notícias sobre isto.
o tim heuer fez um post falando destas novidades, mas ele destacou como você pode melhorar a performance do designer para trabalhar com silverlight.
[]s
hoje foram feitos diversos anúncios relacionados ao vs2010 e o .net framework 4. a primeira delas é que já está disponível o beta 2 para os msdn subscribers. o beta estará disponível para todos na próxima quarta-feira.
além disto, foram divulgadas a data do lançamento oficial, 22 de março de 2010 e a lista de preços.
estou usando o beta 1 do vs2010 e tenho gostado bastante do que estou vendo. para mais informações sobre o beta 2 acesso o site Visual Studio 2010 and .NET Framework 4 Beta 2. aproveite também para participar dos forúns e para dar o seu feedback.
[]s
o nosso time disponibilizou o rollup 3 para o ax 2009 sp1. entre outras correções ele inclui as correções para a integração fiscal com o softteam.
você pode baixá-lo neste link se tiver acesso ao knowledge base.
semana passada foi anunciada a nova versão do windows embedded. uma das novidades foi a inclusão do silverlight. segundo o press release:
“Silverlight for Windows Embedded is an out-of-browser, native code implementation of Microsoft Silverlight technology used to create rich, immersive UIs on Windows Embedded CE 6.0 R3-based devices.”
“High-fidelity user experiences are created when designers leverage their knowledge of Silverlight, Microsoft Expression Blend and Internet Explorer Embedded, enabling capabilities including panning and zoom, touch, and gesture input to dramatically improve Web browsing and the overall user experience OEMs can deliver right from the box.”
este é um importante passo para expansão do silverlight. e uma grande oportunidade para melhorar a experiência do usuário em aplicações embedded.
recentemente estava lendo um post da elisabeth hendrickson’s comentando um incidente envolvendo joe stump e seu novo software. você pode ler os detalhes sobre este incidente no post dela. não quero entrar em detalhes sobre o problema aqui.
o ponto interessante é a análise que ela faz sobre os comentários do joe sobre quanto o software dele havia sido, ou é, testado. infelizmente é muito comum os desenvolvedores ou toda a equipe de desenvolvimento ter uma alta confiança na qualidade do seu software e dos seus testes.
obviamente a confiança do time no seu produto é necessária e importante. Mas é igualmente importante reconhecer que os bugs indicam pontos de melhorias na aplicação e também nos TESTES. também, infelizmente é comum o menosprezo do bug. tentando mostrar que o erro não é tão grave ou tão comum assim. justificativas como que a aplicação foi muito testada ou que o bug não é grave não deveriam ter espaço em times que realmente querem produzir aplicações com qualidade; e não apenas aplicações que NÓS achamos que tem qualidade.
recomendo a leitura e reflexão do post.
scott hanselman's fez um post interessante sobre as diferente maneiras de testar um site em diferentes browsers. o interessante do post é que ele mostra três possívies abordagens.
as duas primeiras são comuns e muito utilizadas. a última foi lançada no Mix deste ano: Expression Web SuperPreview. é interessante ver em mais detalhes como esta ferramenta funciona.
[]s
Ayende fez uma interessante análise de funcionalidades que apresentam bugs repetidamente. a posição dele pode parecer radical. mas a lição interessante é o relacionamento de falhas constantes a um design mal feito ou ruim.
“Fragile designs are one of the worst enemies that you can have, they will keep dropping things in your lap until you finally fix them once and for all. And I find that usually just starting from scratch on a feature implementation is the best way of doing that.”
[]s
esta é uma discussão antiga: o quanto automatizar e o que é possível testar na interface do usuário. Elisabeth Hendrickson é mestre em testes funcionais.
recentemente ela postou a resposta que deu a uma pergunta que recebeu por email: Fully Automated GUI Testing?. a resposta é bem interessante sobre o quanto pode e deve ser automatizado e o que devemos esperar como resultados nestes casos e o quanto deve ser exploratório e o que se pode esperar de resultado.
recomendo a leitura.
[]s
eu não sou defensor de pair programming. até porque não tenho experiência com xp. recentemente trabalhando em um “side-project” com meu amigo Fabio Vazquez, por diferentes motivos, começamos fazendo pair programming por alguns dias. o resultado foi bem interessante. conseguimos evoluir e defenir o que desejávamos mais facilmente. algumas semanas antes tinhamos tentado definir alguns pontos do design apenas conversando num quadro branco. Mas nada evoluiu tão rápido como nos dias que fizemos pair programming.
se pararmos para pensar fazemos pair programming diversas vezes na nossa vida de desenvolvedor. por exemplo, quando chamamos um colega para nosa ajudar a resolver um problema que não estamos conseguindo resolver. Fato é, que sentando na frente do visual studio com o fábio era bem mais fácil entender o que um ou o outro dizia e também visualizarmos o que queríamos. também rapidamente um ou o outro apontava algum erro de design ou dava uma sugestão.
lendo um post roy osherove li um jeito diferente de fazer pair. eles chamaram de screen pairing. nunca tentei deste jeito então não dá para dizer se é bom ou não. também, não sou, ainda, um defensor de programação em par constante, para todo o desenvolvimento. mas para mim está claro que ela tem o seu valor em momentos específicos do projeto.
talvez na próxima vez que for fazer programação em par vou tentar fazer usando screen pairing.
[]s
recentemente estava conversando com um amigo meu e mencionei que gosto muito mais do que leio do jeremy miller do que eu vejo dele (em vídeo de palestras. é claro!). neste post ele faz uma avaliação interessante, e não crítca, que dois tipos de desenvolvedores.
acho q esta é uma leitura obrigatória para todo desenvolvedor. isto nos ajuda a ter uma visão crítica de nós mesmo. e certamente nos ajuda a melhorar e a considerar quando usar um ou outro caminho.
atualmente tenho me esforçado a mudar a minha maneira de pensar e me tornar mais ALT.NET e seguir pelo segundo caminho.mas isto não é fácil e nem sempre é o melhor caminho.
trabalhei a maior parte do tempo com tecnologias microsoft, gosto muito das tecnologias da microsoft e atualmente trabalho na microsoft. mas gostaria de ver mais pessoas que usam as tecnologias da microsoft pensando mais ALT.NET. não que este seja o melhor caminho necessariamente. mas acredito que isto ajuda a termos (nós desenvolvedores) melhores ferramentas e tecnologias disponíveis.
[]s
esta semana estava fazendo algumas bricadeiras (“estudando”) um pouco sobre BDD. resolvi testar um dos frameworks existentes para .net, o nbehave. baixei o pacote zipado e extrai as dlls em um dos meu drives. escrevi os testes e quando fui executar o teste o seu status ficou “not executed” e a mensagem de erro era “The location of the file or directory <nbehave path> is not trusted.”.
talvez você já tenha se confrontado com este erro. mas temos que concordar que a mensagem não é tão óbvia, embora seja clara. as dll estavam em um dos meu discos da máquina. como este podia ser um local não confiável?
o que acontece é que eu baixei as dll em um pacote zip da internet. então por motivo de segurança o meu windows 7(mas isto também acontece com o vista) bloqueia os arquivos extraídos.
para resolver você precisa ir em cada uma da dll, ou no arquivo zip antes de extraí-lo, clicar com o botão direito em propriedades, e então clicar em unblock.
aí meu teste rodou. tanto esforço por nada. porque decidi usar o storyq, outro framework para BDD. :)
[]s
recebemos bons feedbacks da palestra de unit test. espero que realmente o pessoal tenha gostado.
conforme prometido, o código fonte está disponível no meu site.
[]s
