Olá pessoal,

O DNAD13 acontecerá no Rio de Janeiro, nos dias 02 e 03 de Agosto!

A Lambda3, como sempre, estará presente no evento. Se quiserem conversar com alguns de nós é uma excelente oportunidade.

As inscrições estão ABERTAS, visitem o site: http://dnad.azurewebsites.net

Submetam propostas de palestra através do call for papers: https://docs.google.com/forms/d/1IN3cbm46WVSEQjEx0BXiVXwRkb0gQufbG8xQqR–Ljc/viewform

É a sua oportunidade de palestrar no DNAD e mostrar para toda a comunidade o que você tem feito!

Abraço,
Rodrigo Vidal

1. Detach Collection – através da ferramenta Administration Console, foi realizado o Detach da Collection;
2. Detach Database – através do SQL Server Management Studio foi executado o Detach da base de dados da respectiva Collection;
3. Transferência dos Arquivos – após o Detach da Collection e da respectiva base de dados, os arquivos de dados (extensão mdf) e o arquivo de log (extensão ldf), foram transferidos do drive C: para o drive D:;
4. Attach Database – através do SQL Server Management Studio, foi executado o Attach da base da respectiva Collection;
5. Attach Collection – através da ferramenta Administration Console, foi executado o Attach da Collection.

Após a execução do procedimento descrito acima, todos os desenvolvedores começaram a perceber “perda” de permissionamento na respectiva Collection migrada, não conseguindo a conexão conforme demonstrado na figura abaixo:

Após verificação da instalação do Team Foundation Server e pesquisa dos Updates no site da Microsoft, foi necessária a instalação Update to Team Foundation Server Update 1 (KB2803625).

Dentre as atualizações executadas pelo patch, destacamos na figura abaixo os problemas corrigidos que nos ajudaram finalizar a migração da Collection:

Para obter mais detalhes de todas as correções executadas pelo patch, acesso o link Atualização cumulativa 1 para atualização do Visual Studio Team Foundation Server 2012.

Importante lembrar que essa atualização vale para o Team Foundation Server Update 1. Para quem já possui o TFS 2012 Update 2 os problemas com migração de Collection e permissionamento dos desenvolvedores já foi resolvido.

Abraços e até a próxima,

Vinicius Moura

Essa eu passei durante uma consultoria no cliente. A situação era a seguinte: O Team Build e os agentes estão instalados em máquinas 64bits. Tinha um projeto que precisava ser compilado com algumas informações e dll´s de x86.

Quando mandava rodar normalmente, ele apenas dava um erro falando que não conseguia carregar umas dll´s.

Após fazer um estudo percebi que o msbuild procurava as informações no diretório x64 dos projetos e as informações dentro do arquivo de csproj (que é o arquivo que contém o script de msbuild) mandava procurar dentro do x86. Se eu mudasse essa informação quebrava a compilação na máquina dos Devs e sem ela não funciona no servidor de build. E aí, como resolver ?

Dentro da Build Definition tem um parametro que nós podemos usar justamente para isso.

Como setar o parâmetro:

Vá na sua Build Definition –> Aba Process –> Advanced. Lá tem uma opção chamada: MSBuild Plataform e pronto, todos os seus problemas estão resolvidos!

Por padrão ele vem com a opção Auto, isso significa que ele vai identificar qual é a plataforma do sistema operacional que ele vai rodar e chama o MSbuild.exe daquela plataforma.

Para resolver o problema aqui, simplesmente coloquei a propriedade com o valor X86 e tudo funcionou perfeitamente!

Até a próxima

A Lambda3 foi um dos patrocinadores do evento, que ocorreu na ESIC Business Marketing School.

O tema da minha palestra foi “Scrum em Team Foundation Server: Qualidade ao longo do ciclo de vida da aplicação”:

Empresas no mundo inteiro têm cada vez mais dificuldade para desenvolver e entregar software de qualidade. Os desafios são vários, tais como gerenciar as expectativas do usuário e as mudanças constantes de requisitos, bem como garantir a coesão e o foco do time. Venha ver como o desenvolvimento ágil de aplicações, apoiado sobre o Scrum e o Team Foundation Server 2012, pode ajudar times de desenvolvimento a melhorar seu dia-a-dia de trabalho para entregar software de qualidade a seus clientes.

É sempre bem interessante pôr este tema em discussão. Isso nos dá a oportunidade de lembrar quão danoso pode ser o modelo de “test-last development” (onde o teste é deixado para o final do projeto). Infelizmente tratar qualidade como um afterthought (e achar que testes, por si só, garantem a qualidade do software) ainda são atitudes muito comuns nas empresas. De certa forma, estendemos a discussão que começou na minha palestra do ALM Summit Brasil (“O testador está morto. Longa vida ao desenvolvedor!”).

O evento foi bem legal e suscitou discussões bem bacanas. Espero que todos tenham curtido!

Para os que me pediram durante o evento: minha apresentação está disponível para download no SlideShare:

Em tempo: Queria agradecer mais uma vez o convite da PrimeControl. Nos vemos no ano que vem!

Um abraço,
Igor

No último mês trabalhei em uma PoC e nela temos que validar alguns cenários especificos. Um desses cenários era trabalhar com códigos-fontes que são desenvolvidos apenas em máquinas que rodam Linux.

Até aí nada demais vocês podem falar, afinal posso usar o Team Explorer Everywhere (TEE) que vai resolver meu problema, ou posso usar o TFS e Git como demonstrado pelo Giovanni Bassi nesse post (http://blog.lambda3.com.br/2013/01/tfs-agora-suporta-git/) .

Mas imagine que você está trabalhando com um ambiente de TFS local e não o TF Service (que é o único que suporta Git) e ainda tem aquele usuário de linux que gosta de usar apenas linha de comando, ou por algum outro motivo, não possa ou não queira instalar o Eclipse para rodar o TEE.

Para esse cenário, podemos usar o Cross-platform Command-Line Client for Team Foundation server.

Nesse link tem os passos necessários para você baixar e configurar o command line. Mas e aí, como eu uso para poder fazer o meu check-in e check-out ?

Primeiro temos que aceitar o End User License Agreement (EULA), para isso, na pasta onde você descompactou o zip digite:

tf eula

Vá até o final do arquivos e aceite os termos.

Depois de aceitar o EULA, vamos agora facilitar as coisas um pouco. Os comandos que vamos usar sempre pedem que passemos como parametros a collection vou realizar a operação, usuário e senha. Para evitar de ficar sempre digitando as informações, sugiro criarmos um alias no bash, assim além de em qualquer lugar você apenas digitar o tf  e o seu S.O entender podemos também já colocar essas informações que sempre precisariamos usar. Para isso, digite o seguinte na sua console:

alias tf=’local_onde_voce_descompactou_o_script/tf –login:(seu_usuario)@dominio.(Senha) –collection:http://end_servidor:porta/tfs/nm_collection

Com o nosso alias configurado vamos criar o nosso workspace, para isso, crie uma pasta na sua home, como por exemplo ProjetoNoTFS com o seguinte comando:

mkdir ~/ProjetoNoTFS

Agora vamos criar o nosso workspace no TFS, para isso digite:

tf workspace –new –location:local –permission:Private

Existem outros parametros, para ter uma lista completa, digite apenas ./tf

Depois de ter o workspace criado, vamos mapear a working folder, para isso, digite:

tf workfold –map (pasta_no_servidor) (pasta_local) –workspace:(nome_do_workspace)

Agora podemos baixar todos os arquivos que já estão no repositório. Entre na pasta que acabamos de mapear e digite :

tf get

Agora podemos editar as informações e fazer um checkin, no meu caso, vou adicionar um arquivo txt que criei no Linux. Para isso digite :

tf add  (nome_do_arquivo)

Agora vamos fazer um checkin, para isso digite:

tf checkin  (nome_do_arquivo) –comment:“comentario que quiser”

se quiser vincular um workitem no checkin, utilize o parametro –associate ou -resolve

e para fazer o checkout :

tf checkout  (nome_do_arquivo)

Espero que tenham gostado.

Até a próxima

Imaginem o seguinte cenário, um desenvolvedor que trabalhava no seu projeto pediu demissão e um novo desenvolvedor foi contratado para trabalhar em seu lugar. Antes de liberar a máquina para o novo desenvolvedor, geralmente a máquina com as configurações originais é formatada e preparada para o novo desenvolvedor.

Perfeito, temos tudo pronto e o desenvolvedor novo já pode começar a trabalhar. Assim que ele abre o Visual Studio, esse novo desenvolvedor vai criar seu workspace para “baixar” seu projeto em uma pasta padrão. Ao fazer isso ele pode receber uma mensagem, informando que já existe um workspace vinculado no Visual Studio.

E agora? o desenvolvedor antigo já foi embora. A máquina que ele usava já foi formatada. Como podemos apagar essa informação do servidor e libere a máquina para outro usuário?

Outra situação, seu desenvolvedor saiu de férias e esqueceu de fazer o check-in de alguma coisa que ainda estava trabalhando e outra pessoa da sua equipe precisa mexer nesse(s) arquivo(s). Como podemos liberar esses arquivos?

Existem duas maneiras, uma é via linha de comando, porém nada amigável e a outra é usando uma excelente ferramenta que ajuda na administração do seu Team Foundation Server: Team Foundation Sidekicks

Essa é uma das ferramentas que utilizo muito e sempre passo para o clientes para ajudar na administração do TFS.

Até a próxima!

Dia 20/4 ministrei uma palestra de Git no ALM Summit 2013. A palestra foi filmada, e em breve teremos o vídeo.

Enquanto isso vocês podem ver os slides. Estão abaixo:

Algumas referências:

Site do Git: http://git-scm.com/

Podcast sobre DVCS: http://www.tecnoretorica.com.br/2012/05/dvcs/

Video do Linus explicando porque Git: http://bit.ly/linusgit (Video)

Excelente livro gratuito sobre Git: http://progit.org/

Artigo avançado sobre internals do Git: http://bit.ly/gitfrombottomup

Tag de Git no blog da Lambda3: http://blog.lambda3.com.br/tag/git/

O que segue abaixo foram anotações que fizemos durante a sessão, com alguns tópicos. Nosso objetivo aqui não é explicá-los e sim registrá-los, se você quiser entender melhor cada um dos tópicos é só chegar aqui na Lambda3 que a gente fala sobre eles

O tempo foi suficiente para discutirmos 5 tópicos do capítulo 2 – Meaningful names

• Intention revealing names
• Avoid disinformation
• Make meaningful distinctions
• Use Pronounceable names
• Use Searchable Names

Intention revealing names

• Intention revealing names é dependente do domínio e do contexto em que a interface em questão esta sendo usada. O programador tem que conhecer o domínio, caso contrário a interface dificilmente será reveladora.
• Bons nomes dependem bastante das experiências de cada um, sendo assim um nome que é razoável para um desenvolvedor pode parecer o nome ideal para outro, e vice-versa.
• O preciosismo com nomes deve ser evitado.
• Alguns casos como no C# foi escolhido mudar uma interface para o público alvo entender melhor. Como exemplos temos o Linq com os métodos Reduce/Fold
• Há diferenças em IRN(Intention revealing names) em linguagens estaticamente tipadas e em linguagens dinâmicas. Chegamos ao questionamento se a recomendação em linguagens dinâmicas é usar o tipo como parte do nome.

Desinformation

• Programar em idiomas estrangeiros requer cuidado extra para nomeá-los. Buscar o nome significativo para ter certeza se o nome  corresponde ao que você esta querendo dizer.
• Bad smells: descrever imperativamente no nome método exatamente como faz. Você deve descrever o que ele faz.
• Membro novo no time tende a criar nomes descontextualizados.

Make meaningful distinctions

• Palavras genéricas não servem para distinguir conceitos. DadosAdicionais
• Plural são distinções significativas? eg: ObterUsuario() x ObterUsuarios()

Use Pronounceable names

• A linguagem de domínio utilizada pelo Product Owner as vezes não representa a linguagem ubíqua. No caso de um nome ruim, você pode sugerir um nome melhor.
• Buscar conhecimento de outras pessoas é interessante mas deve tomar cuidado pois uma mesma coisa pode ter nomes diferentes em contextos diferentes.

É isso pessoal, esse é apenas um relato da nossa discussão. Esperamos em breve conseguir tornar a discussão pública, aguarde novidades

Participaram desta discussão:

• Bernardo Rosmaninho
• Higor Cesar Ramos
• Rodrigo Vidal

Abraço.

Gravei um podcast pro Tecnoretórica com o Juliano Alves sobre programação funcional. Falamos de Scala, F#, e alguns conceitos básicos. Se você quer conhecer o assunto, é uma boa pedida.

Ouçam lá: http://www.tecnoretorica.com.br/2013/04/programacao-funcional/

E já assinem o RSS: http://feeds.tecnoretorica.com.br/tecnoretorica

Também na iTunes Store, e no Windows Phone Marketplace:https://itunes.apple.com/pt/podcast/tecnoretorica/id374959406

Ministrei uma palestra de Git no último sábado e reparei que não tinha postado aqui no blog sobre o bate papo que tive com o Raphael Molesim e o Juliano Alves sobre DVCS, Git e afins. Então estou resolvendo esse problema com esse post.

Ouçam lá: http://www.tecnoretorica.com.br/2012/05/dvcs/

E já assinem o RSS: http://feeds.tecnoretorica.com.br/tecnoretorica

Também na iTunes Store, e no Windows Phone Marketplace: https://itunes.apple.com/pt/podcast/tecnoretorica/id374959406

Eu já havia publicado os slides e informações em outro post aqui no blog.

Enjoy.

Tecnicamente falando
A idéia foi organizar um evento pragmático focando no conteúdo que estamos aplicando durante o desenvolvimento de projetos e consultorias. O Victor Hugo fez as honras de abrir o evento apresentando a Lambda3 e falando um pouco sobre os três anos de vida da empresa.

Eu fiz isso através da minha apresentação sobre Orientação a objetos. Vejam os slides de todas as apresentações no final deste post.

Comunidade
Todos nós ficamos impressionados com a velocidade com a qual os ingressos se esgotaram. Em apenas um dia, todas as 50 vagas acabaram! Fica aqui o agradecimento à comunidade pela participação e divulgação do evento. O feedback serviu para nos mostrar que o próximo LambdaDay (que ainda não tem data) será um evento bem maior, e contamos com vocês para isso.

Ao término do evento tomamos um chopp e rolou uma interação melhor com a galera, vejam como foi:

Slides das apresentações

Orientação a objetos nas trincheiras

Introdução ao NHibernate

O código utilizado para a palestra de Introdção ao NHibernate está disponível no GitHub.

Overview sobre Transição Ágil

É isso pessoal, fiquem ligados no blog da Lambda3, pois muito conteúdo ainda está por vir.

No último mês de Março foi realizada a primeira edição do Lambda Day. Dias 08 e 09 no Rio de Janeiro e São Paulo, respectivamente. Como não pude participar do evento do RJ, minha intenção aqui é falar um pouco sobre o evento realizado em São Paulo.

A idéia do Lambda Day surgiu há aproximadamente um ano atrás, e ainda não sabíamos exatamente como o evento deveria ser. A idéia foi sendo processada aos poucos, diversas discussões internas surgiram e depois de muito se refletir a respeito, a idéia finalmente saiu do papel e decidimos realizar esse evento para contar um pouco da história da empresa, tudo o que passamos nesses três anos de vida e compartilhar nossas experiências. Experiências boas e ruins, mas que fizeram a Lambda3 amadurecer, crescer e ter a oportunidade de apresentar tudo isso para a comunidade, através desse evento.
Foi um evento pequeno, com apenas 50 vagas abertas ao público aqui em SP. No entanto, essas 50 vagas esgotaram-se em menos de 24 horas, o que indicaria que o evento seria um sucesso. E felizmente foi. Encontramos diversos membros da comunidade, amigos, clientes e parceiros. Pudemos conversar, trocar experiências, discutir e aprender com cada participante.

Palestras
A missão dos palestrantes era entregar conteúdo de qualidade, à altura da Lambda3. Felizmente, acredito que conseguimos alcançar essa meta.
Embora os temas tenham sido bastante variados (desde marketing de produtos digitais até programação funcional), os temas não foram escolhidos ao acaso. Em cada uma das palestras colocamos um pouco do que vivemos em diversos projetos e consultorias.
Todos os palestrantes trabalham na Lambda3, e embora alguns deles sejam bastante experientes, todas as pessoas tiveram a oportunidade de participar. Eu, por exemplo, nunca tinha palestrado em nenhum evento e a ajuda dos mais experientes fez com que eu me sentisse bastante seguro para fazer isso.

Não vou citar cada palestra individualmente pois muito conteúdo foi apresentado. No entanto, aproveito para compartilhar os slides das paletras de São Paulo:

Keynote Lambda Day

Marketing de Produtos Digitais

Web Design Responsivo

Técnicas de Programação Funcional

Backbone.js nas trincheiras

O código da aplicação de exemplo utilizada na palestra de Backbone.js está disponível no GitHub.

Novidades ALM Summit 2013

Experiências, Erros e Acertos no Desenvolvimento de Projetos Ágeis

Lightning Talk – Jquery – Dicas e Truques

Lightning Talk – Source Control

Lightning Talk – Como você está criando os seus objetos?

Valor da inscrição
Como informado no post do anúncio do evento, todo o dinheiro arrecadado com as inscrições em São Paulo (descontando-se a taxa de serviço do site de vendas que é de 10% do valor da inscrição) foi doado para a Associação Educacional Casa do Zezinho.

Erros cometidos
Sim, cometemos erros. Erros que conseguimos contornar durante o evento, mas que poderíamos ter evitado com um pouco mais de atenção. O principal problema foi o endereço errado no site do evento (a numeração do local estava incorreta), o que gerou atraso no evento de SP. Aproveito esse espaço para pedir desculpas à todas as pessoas que participaram e que foram, de alguma forma, afetadas.

Feedbacks
Felizmente, dado todos os feedbacks que recebemos durante e após o evento, acredito que conseguimos atingir o objetivo. Todas as palestras foram muito bem avaliadas, o que nos deixou muito mais confiantes para realizar o próximo Lambda Day.

Eduardo Santos: “Quando ao Lambda Day, eu que tenho que agradecer pelo excelente trabalho. Tenha certeza de que o compartilhamento de conhecimento realizado por vocês influencia positivamente na formação profissional de muitas pessoas. Tanto na formação filosófica, quanto técnica.” (sic)

Jonas Abreu: “O evento foi um dos melhores que participei nos últimos anos.” (sic). http://www.vidageek.net/2013/03/11/lambda-day/

Agradecimento
Quero agradecer todos os participantes, todas as pessoas que foram ao evento no sábado de manhã, assistiram as palestras e interagiram conosco. A participação de vocês foi fundamental para o sucesso do Lambda Day.

Publicado originalmente em http://www.osmarlandin.net/index.php/2013/04/conteudo-do-lambda-day-sp-2013/ (18/04/2013)

Há muito tempo o processo de controle de qualidade (QA, Quality Assurance) de software – em especial, as práticas de teste que são parte desse processo  – é tratado como um afterthought. Ou seja, na maioria dos projetos o controle de qualidade em geral (e os testes, mais especificamente) são relegados a um papel de menor importância e muitas vezes sequer fazem parte do planejamento do projeto.

“Se der tempo, na última semana antes da entrega, a gente testa. “ Vai dizer que você nunca ouviu isso?!

A luta do pessoal de QA para ser envolvido cada vez mais cedo no projeto é travada constantemente, mas às vezes parece inglória. Não importa o quanto se argumente, parece que o foco está sempre no desenvolvedor.

Como se não bastasse isso tudo, tem gente dizendo que os tais “agilistas” pregam que não precisam mais de testadores. Que o desenvolvedor resolve tudo. O Scrum é ainda mais explícito ao declarar no Scrum Guide (http://www.scrum.org/Scrum-Guides) que:

“Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule” (Scrum não reconhece títulos/cargos para membros do Time de Desenvolvimento além de Desenvolvedor, independentemente do trabalho realizado por aquela pessoa; não há exceções para essa regra); e

“Development Teams do not contain sub-teams dedicated to particular domains like testing or business analysis” (Times de Desenvolvimento não contêm sub-times dedicados a domínios particulares tais como testes ou análise de negócios).

Quer dizer que não há testadores num time ágil? Apenas desenvolvedores?

É isso aí. E a tendência é que as coisas fiquem cada vez piores para os testadores, se considerarmos que a adoção de práticas ágeis de desenvolvimento (tais como o Scrum) continuam crescendo.

Eu não disse que o fim estava próximo?

Claro que as coisas não são tão simples assim. Na verdade o que há é um grande mal-entendido sobre o que o Scrum Guide realmente quer dizer quando afirma que “todo mundo é desenvolvedor”. De maneira geral, nossa comunidade entende que desenvolvedor é sinônimo de programador e, portanto, o Scrum Guide estaria dizendo que um time é composto exclusivamente de programadores.

Nada mais falso.

Desenvolvedor é “aquele que desenvolve algo”, certo? Para desenvolver um produto complexo como um software é preciso muito mais do que produzir código. É preciso entender de negócios, de bancos de dados, de redes e infraestrutura… E também é preciso saber testar software!

O assunto é tão importante – e tão polêmico – que resolvi “cutucar a onça com vara curta” e palestrar sobre ele. Se quiser discutir o assunto, venha participar do debate no ALM Summit Brasil 2013 no próximo sábado (dia 20 de abril). Todas as opiniões serão mais que bem-vindas!

Ah, eu também submeti uma proposta para o Agile Brazil 2013 para esta mesma palestra. Se minha submissão (que ainda está sob avaliação) for aprovada, poderemos também discutir sobre esse assunto em Brasília. Espero por vocês em São Paulo e (tomara!) também em Brasília.

O que você acha do assunto? Não deixe de comentar…

Um abraço,
    Igor

O pessoal da Lambda3 fez diversas submissões de palestras pro AgileBrazil, todas muito interessantes. As propostas tem espaço para comentários, convido todos a irem até lá e dizerem o que acharam, esse feedback é muito importante.

Vejam abaixo os assuntos que queremos abordar (em ordem alfabética).

• Agilidade está muito além de modelos e ferramentas (Juliano Alves)
• Comunicando com efetividade com Comunicação Não Violenta (Giovanni Bassi)
• Democracia organizacional: o próximo passo depois da agilidade (Giovanni Bassi e Victor Hugo Germano)
• Experiências, Erros e Acertos em Desenvolvimento de Projetos Ágeis (Raphael Molesim e Victor Hugo Germano)
• Indicadores são malígnos. Verdade ou mentira? (Giovanni Bassi)
• O testador está morto. Longa vida ao desenvolvedor! (Igor Abade)
• Sendo ágil com Single Page Applications (Giovanni Bassi e Victor Cavalcante)

Além de torcermos para as propostas serem aceitas (a concorrência é grande e há muitas submissões boas além das nossas) também estamos mais uma vez patrocinando o evento. Participamos do AgileBrazil desde sua primeira edição, patrocinando, coordenando, palestrando e, lógico, como congressistas. Se você não foi ainda, recomendo muito que esteja lá esse ano. E se já foi, já sabe que é bom. De qualquer forma passe no nosso estande esse ano para nos dar um olá e bater papo.

O evento foi ótimo, revi algumas pessoas que já conhecia, e conheci outras. O Elemar Jr. estava presente também, e é sempre legal bater um papo com ele, principalmente porque ele insiste pra que eu aprenda C++ e eu pra que ele aprenda CoffeeScript.

A BluData com quem eu já havia trabalhado no passado e que patrocinou o evento, através do Zote, me convidou para a palestra. Agradeço o Zote e o Rafael Leonhardt, que organizou o evento, pelo convite. Vocês podem ver os comentários do evento no twitter pela hashtag #bludotnet.

Os slides estão abaixo:

E aqui algumas referências:

• Home page do WEB Api
• ASP.NET no Codeplex
• WEB Api no blog da Lambda3

Espero que tenham gostado.

Já publicamos os slides e falamos um pouco sobre a palestra anteriormente. Vejam aqui no blog.

Espero que gostem. Comentem aqui o que acharam.

Durante os projetos que trabalhei assumi débitos técnicos diversas vezes, algumas por falta de conhecimento do negócio, outras vezes por falta de expertise técnica e algumas outras por pressão dos stakeholders. Como o elemarjr diz nesse post, eu ganhei experiência e pude aprender quais eram os momentos ideias para assumir esses débitos. Quero compartilhar aqui parte do aprendizado que obtive nós ultimos anos:

1. Dívidas técnicas são plausíveis quando existe um release em produção do sistema. Com release quero dizer respeitar o time to market.
2. Deixar de escrever testes não favorece a velocidade de um time maduro, nem mesmo temporariamente.
3. Dívidas técnicas devem estar visíveis!
4. Dívidas técnicas devem ser pagas de tempos em tempos.
5. As dívidas não devem servir como um aditivo para performance do time.
6. Não devemos contar com a capacidade do time de assumir dívidas.
7. Precisamos limitar o endividamento.

Esta lista poderia ser maior, no entanto acredito que com as dicas acima já conseguimos tratar as dívidas de uma forma melhor do que eu vejo times trabalhando no mercado.

Para fechar eu acho que é importante relacionar as dívidas com a teoria das janelas partidas ou ainda com o princípio de pareto. Assim fica mais facil entender como as dívidas podem criar juros e ainda decidir a melhor forma de assumi-las, repetindo que não escrever os testes sem dúvida não é a melhor forma.

Hoje dia 26.03 eu tive a oportunidade de palestrar no MVP Virtual Conference. Foi um grande prazer! Ser escolhido para falar junto com os MVP´s de ALM realmente foi uma honra, espero ter atendido a todas as expectativas e de todos!

Na palestra eu comentei sobre os  Alm Rangers, o Guide de Branch & Merge e o plug-in que instalado no Visual Studio nos ajuda a criar a nossa estrutura inicial de branch e guide.

•  Branch & Merge Guide
• Plug-in do Visual Studio 2012

Surgiram perguntas em como poderíamos trabalhar com o Xcode e o TFS, como trabalhar em sistemas não Windows e o TFS para gerenciar minhas branches. Vou preparar essa semana alguns post sobre esses cenários.

Eu já tinha feito uma palestra sobre Branch e Merge no ALM Summit 2012 e acabei escrevendo um post completando algumas informações, quem quiser, pode acessar o post no link: http://blog.lambda3.com.br/2012/05/minha-palestra-no-alm-summit-brasil-2012/

Querem conhecer mais sobre ALM, não percam o ALM Summit Brasil 2013!!

Já imaginou você ir para um evento, ver as melhores práticas de ALM e ainda poder ganhar um XBOX ??

Para maiores informações : http://www.almsummitbrasil.com.br/

Espero que tenham gostado da palestra e em caso de dúvidas, deixem seus comentários ou enviem por twitter ou e-mail.

Abs!

O processo de publicação é muito simples, basta autorizarmos o Windows Azure a utilizar nosso serviço Dropbox, essa autorização criará uma nova pasta compartilhada (geralmente no caminho /Dropbox/Apps/Azure) em que poderemos manter nossa aplicação/site para publicação. Esse método de publicação é válido para todos os tipos de projeto suportados pelo serviço Windows Azure SDK, nesse exemplo publicaremos uma aplicação ASP.NET MVC.

Podemos ir no portal do Windows Azure e criar nosso Windows Azure Web Site escolhendo o Dropbox como o serviço de publicação.

Será requisitado que você dê acesso ao serviço do Windows Azure em seu Dropbox.

Você terá a opção de criar uma nova pasta ou já utilizar alguma existente, como já tenho meu projeto criado eu apenas moverei ele para a pasta em que o Windows Azure tem acesso e o escolherei.

E pronto! Se não houver nada de errado com nossa aplicação, ela estará no ar após o processo de publicação.

Caso queira publicar alguma alteração feita basta utilizar o botão “Sync” que o Windows Azure realizará uma nova publicação e assim como nas outras formas de publicação será mantido o histórico de publicação tornando muito simples a possibilidade de retornar a alguma versão anterior.

O site foi realmente publicado!
http://azurelovesdropbox.azurewebsites.net/

É isso pessoal, bem simples.
Abraços

Publicado originalmente em http://dyegocomy.com/blog/deploy-windows-azure-via-dropbox/ (21/03/2013)

Quem acredita que as pessoas precisam ser empurradas defende a existência do gerente (e seus semelhantes: diretores, presidentes, etc). E eles tem dados, vão mostrar diversos casos em que, não fosse o gerente, as pessoas não estariam trabalhando com tanta dedicação.

Quando a Teoria X e a Teoria Y surgiram, e junto com outros estudos começaram a demonstrar a falibilidade do argumento de que o gerente era necessário, começaram a surgir correções no modelo de gestão tradicional. Os donos do poder (modernos feitores de escravos), ávidos por não perderem esse poder, e com ele seu status, começaram a ~se adaptar~ aos novos tempos. Isso significava aumentar um pouco o tamanho da corrente que prendia o funcionário a mesa. Mas ela continuava lá. Com isso nasceu o horário flexível, a meta extendida, entre outras pseudo-liberdades, que nada mais eram do que novas formas de manter o controle.

O X da questão (já que estamos na letra) e que a gestão tradicionalista ainda não entendeu, é que os gerentes são a causa da falta de iniciativa e motivação dos próprios funcionários que eles gerenciam. É a falta de autonomia que advém da mera existência do gerente uma das maiores causadoras da apatia encontrada em tantos escritórios mundo afora.

Quando motivada externamente a fazer uma atividade, mesmo se for algo que se gosta naturalmente, a motivação intrínsica que impulsionava anteriormente sofre. Algo que antes era prazeroso, agora que é impulsionado por uma recompensa externa torna-se menos interessante. Tire da pessoa a sensação de escolha de fazer ou não fazer algo, e verá sua vontade de fazê-lo diminuída. Autonomia, tem-se comprovado, é o principal motivador que podemos encontrar, superando outros motivadores instrínsecos, como o senso de contribuição. Pesquisas feitas há décadas por Edward Deci, que resultaram na Teoria da auto determinação (Self Determination Theory, ou SDT), mostram que incentivos externos, como bônus ou promoções, removem do trabalhador a sensação de estar dirigindo as próprias escolhas, o que acaba matando suas motivações iniciais, como a paixão por determinado assunto. Os estudos foram comprovados inúmeras vezes em laboratório, pela chamada psicologia comportamental, uma divisão da psicologia que não se contenta em dizer que algo funciona baseado apenas em achismos, mas vai ao laboratório testar suas hipóteses.

Como resolver? Livremo-nos dos gerentes, e busquemos uma nova palavra. Muitas começam com “auto”: auto-motivação, auto-gestão, auto-organização. As pesquisas de Douglas McGregor, criador da Teoria Y,  mostram que os limites de produtividade e os resultados são muito menores, algo que ele apresentou no seu livro The Human Side of the Enterprise, a nada menos do que 50 anos atrás.

No desenvolvimento de software já aprendemos a fazer isso: chamamos de desenvolvimento ágil. A gestão na nossa área já está um passo adiante, ainda que não toda ela. Temos sorte. E as outras áreas tem começado a perceber, já que revistas como a Forbes e Harvard Business Review, tradicionalistas em diversos assuntos, mas ainda assim pragmáticas, tem insistindo em divulgar as novidades, ainda que em agile menos baseadas em pesquisas, são baseadas em fatos e resultados.

De fato, os gerentes vieram pra ~resolver~ um problema. Só não perceberam que eles mesmos eram os causadores do problema. A ciência já provou que podemos ser melhores. Falta apenas as empresas abandonarem suas crenças que não possuem qualquer embasamento na realidade e adotarem o que a academia já descobriu a décadas.

Em que tipo de empresa você trabalha? Em uma em que os gerentes acreditam que precisam motivar os trabalhadores com motivadores externos (além de acreditarem no saci e no papai noel)? Ou em uma em que utiliza os conhecimentos científicos que a engenhosidade humana foi capaz de produzir no último século?

E você? Que tipo de pessoa você é? Acha que bônus motivam ou desmotivam? Se ainda se apega às antigas crenças, talvez seja a hora de buscar entender um pouco mais sobre como as pessoas funcionam. Fica a dica.

No dia 16/03/2013 ministrei uma palestra de Node.js no Azure Summit Brasil 2013. Apesar de ser um evento sobre Azure, foi praticamente uma pelestra sobre Node.js. Mostrei ele funcionando com o Express.js, um framework MVR para Node, servindo páginas dinâmicas web, além de um serviço com websockets e long pooling baseado em Socket.io. Nem abri o Visual Studio, todo o desenvolvimento foi feito no Sublime (se estivesse no Linux seria o VIM, mas era uma demo com Windows). Depois subi tudo pro Azure com git, usando as ferramentas de linha de comando do Azure, baseadas em Node também (ou seja, cross platform, funcionam bem também no Linux e Mac). E então consumi os serviços de uma aplicação Windows 8 feita na hora com Html, Javascript e CoffeeScript.

O feedback foi ótimo (aqui tem um feedback legal sobre o evento como um todo e cita minha palestra lá no final), os desenvolvedores adoraram o Node.js, que é bem simples e muito poderoso.

O código final está no meu github:

https://github.com/giggio/Exemplo-NodeJS-com-Azure

Vou fazer um vídeo com a demo e subir pro Youtube no nosso canal, o Lambda3TV. Já tem outros vídeos lá mostrando coisas parecidas. A demo é muito divertida e acho que muita gente vai gostar.

Pra saber mais sobre Node.js no Azure, tem uma área destina a ele no site:

http://www.windowsazure.com/en-us/develop/nodejs/

Os slides estão abaixo.

Até o próximo!

* Update:
O vídeo da palestra foi postado no Youtube:

Na Lambda3 colocamos quase todos nossos serviços na nuvem. Servidores de ALM, hospedagem de blog, site, controle de projetos, CRM, email, portal, etc. Basicamente o que fica nos nossos sevidores internos são servidores de diretório (Active Directory, no caso) e Firewalls. Faz sentido, a empresa é nova, pra que nascer com algo que pode ser muito mais bem gerenciado por um terceiro na nuvem e mais barato. Pagamos para terceirizar o que não é nosso core business.

Nosso e-mail está com a Microsoft, usamos o serviço do Office 365, com uma conta Enterprise, que nos dá direito inclusive a licenças de Office Pro Plus 2013. Junto nessa conta recebemos ainda um portal do Sharepoint, que vem com Word Web App, Excel Web App, além de Wiki, que usamos bastante. Com o serviço do Office 365 as pessoas da Lambda3 ganharam um endereço de email tipo fulaninho@lambda3.com.br. No entanto, o tal fulaninho tem também um login na rede da Lambda3, com o mesmo e-mail. Assim, ele tinha duas senhas: uma para a rede da Lambda3, outra para o e-mail, portal, wiki, etc.

O legal é que a Microsoft oferece uma maneira de você expor a autenticação dos usuários na internet, usando o Active Directory, e padrões abertos. É o Active Directory Federation Services (ADFS). Com o ADFS expomos um Secure Token Service (STS) que faz o trabalho de autenticação, e redireciona a pessoa para o site original, além de responder a chamadas de serviços (web services). Aqui nesse documento mostra como o ADFS.

E mais legal ainda é que eles implementaram suporte a um STS no Office 365. Assim, retiramos a senha dos usuários do Office 365, e o usuário ele é redirecionado para o STS da Lambda3, que o autentica e o devolve para o site do Office 365 que ele está tentando acessar (portal, webmail, etc). Os serviços do Office 365, como por exemplo, Exchange (que hospeda os emails e sincroniza com o Outlook e client de email de celular e Windows 8), também falam com o STS. Temos o single sign on funcionando.

Além disso, habilitaram a sincronização dos usuários do AD no Office 365. Assim, posso subir todos os usuários da rede Lambda3 para o Office 365, e qualquer mudança (nome, sobrenome, telefone, etc) reflete de imediato.

Passei umas 12 horas arrumando esse ambiente (temos 30 pessoas na Lambda3 mais ou menos). Não foi exatamente rápido, já que tive que aprender como se fazia pra configurar tudo, inclusive nosso firewall, mas posso dizer que gastei umas 4 horas só sincronizando as contas. Se 2 contas são iguais (o mesmo usuário, mesmo e-mail) mas os dados diferem (nome, sobrenome, nome completo e e-mail), ele não sincroniza. Tive que arrumar tudo na mão, porque ainda não há uma maneira mais inteligente de fazer (imagino que isso deve ir melhorando com o tempo).

Como os protocolos usados são padrões, imagino que poderei começar a usar o single sign on unificado com qualquer serviço que suporte os serviços, baseados em SAML.

Mas ao final tudo funcionou. O resultado pode ser visto em diversos lugares. Por exemplo, aqui é o site do Office 365. Ele pode ser acessado via http://portal.microsoftonline.com.br:

A administração é feita também via Windows Azure Directory, que ainda está em preview, acessível via https://activedirectory.windowsazure.com. Imagino que em algum momento essa interface vai para dentro do portal do Azure. Por enquanto não nenhuma feature nova, fora uma interface gráfica mais amigável. Notem a sincronização e o single sign on estão habilitados:

Os usuários listados. Notem que os usuários listados como “In Cloud” não estão no AD da Lambda3, e os que estão “Synced with active directory” estão na nuvem e na Lambda3:

Não podemos alterar os dados de um usuário sincronizado, isso é feito diretamente no nosso AD, e depois sincronizado.

Podemos atribuir a um usuário (sincronizado ou não) uma licença do Office 365, que lhe dá acesso a email, Office Pro, Exchange, etc.

Aqui um gif animado mostrando o login (clique para ampliar):

Gostei muito do resultado final. Vamos continuar investindo no uso de serviços em nuvem. Poupam muito nosso tempo tendo que administrar tudo isso.

Falando sobre o que importa, eu estou lendo o livro Pro ASP.NET MVC4 e vou falar sobre algumas coisas legais que não vejo pessoas falando normalmente sobre as capacidades do framework, e uma das features pouco exploradas são as rotas, então vamos ver um pouco mais sobre elas.

Priorizando controllers por namespace
Quando o mvc recebe uma requisição o sistema de roteamento analisa a rota e identifica quem deve responder a requisição, ou seja quando realizamos uma requisição para a url:

http://localhost:61049/Home/Index

O sistema de roteamento procura por um controller de nome HomeController de forma desqualificada, ou seja, independente do namespace. O framework não sabe o que fazer quando por exemplo existe um controller com o mesmo nome em outra pasta. por exemplo, se criarmos um HomeController dentro de uma pasta additional teremos o seguinte erro:

Para resolver esse problema podemos priorizar controllers usando o namespace. Então se quisermos que o controller dentro da pasta additional seja priorizado basta configurar o namespace no roteamento, segue o exemplo:

routes.MapRoute(
  name: "Default",
  url: "{controller}/{action}/{id}",
  defaults: new { controller = "Home", action = "Index",
  id = UrlPa  rameter.Optional },
  namespaces: new[]
  {"ASPNETMVC4.Exemplos.RotasPorNamespace.Controllers.Additional",}
);

Com o código acima o framework vai priorizar o namespace configurado e caso não encontre o controller no namespace então qualquer controller, independente de namespace será utilizado.
O último detalhe é tomar cuidado para não priorizar mais de um namespace com um controller do mesmo nome, se mais de um namespace estiver configurado o erro acontece novamente, exemplo:

routes.MapRoute(
  name: "Default",
  url: "{controller}/{action}/{id}",
  defaults: new { controller = "Home", action = "Index",
  id = UrlParameter.Optional },
  namespaces: new[]{
    "ASPNETMVC4.Exemplos.RotasPorNamespace.Controllers.Additional",
    "ASPNETMVC4.Exemplos.RotasPorNamespace.Controllers"
    }
);

É isso pessoal, o código de exemplo está no GitHub.

Esse artigo foi postado também em higorcesar.com.br

Aplicações web sempre tiveram na experiência do usuário um revés.
Padrões abertos que atendem pelo nome HTML5 agora lutam no lugar dos derrotados Adobe Flex e Microsoft Silverlight.
Do outro lado do campo de batalha estão as tecnologias nativas, finalmente desafiadas por um adversário que assusta.

Em meio a outras inovações surgiu a atual proposta de Single-page applications (SPA).
Por que subutilizar o lado do cliente enquanto sobrecarregamos o lado do servidor?
Por que não equilibrar melhor esta carga?
Além do maior equilíbrio também conseguiremos melhorar a experiência proporcionada ao usuário da aplicação por meio de maior ênfase nas técnicas de front-end development.

Some a estas novas idéias um rápido crescimento da comunidade técnica JavaScript.
O terreno parece ser fértil para todos que ousarem mudar de direção.

Na prática desenvolver uma aplicação SPA significa:

• Escrever menos código server-side e mais código client-side
  (Consequentemente precisamos aprofundar nossos conhecimento de JavaScript)
• Organizar da melhor maneira possível este código JavaScript
  (Normalmente com ajuda de um framework)
• Mais oportunidades para proporcionar uma melhor experiência ao usuário

Qual a visão da Microsoft?

A Microsoft tende a suportar cada vez mais este novo jeito de desenvolver para a web. Alguns indícios para isto são:

• Investimento no Web API
• Investimento em ferramental, incluindo também a disponibilização de um template SPA para o ASP NET MVC
• Publicação de conteúdo voltado ao engajamento de desenvolvedores
• Trazer padrões web para dentro do Windows
• Investimento em TypeScript

Quando apostar em SPA?

A primeira grande motivação para SPA é o potencial para melhorar a experiência do usuário da aplicação.
É provável que Trello, Foursquare, Code School e DocumentCloud sejam exemplos de aplicações tocadas por esta motivação. Dentre muitas outras estas empresas apostaram no uso de Backbone.js (atualmente o framework SPA em maior evidência).

Do ponto de vista técnico, uma motivação arquitetural é a melhor separação das responsabilidades de cliente e servidor.

Uma importante implicação é a mudança de ferramental.
Para apostar em SPA precisamos buscar expertise em padrões web, principalmente JavaScript.

SPA também parece uma boa opção para aplicativos móveis.
LinkedIn, Walmart e SoundCloud apostaram no Backbone.js para construir seus aplicativos.
Talvez pelo fato dos padrões web possuírem mais força de trabalho que as tecnologias nativas.

Como vimos muitas empresas inovadoras apostaram em Single-page applications. Os gráficos a seguir sustentam a tese de que o tema está em evidência.

Só o futuro vai mostrar aonde tudo isso vai parar.

No fundo SPA é mais uma buzzword fabricada no mercado de tecnologia, mas agora você já sabe tudo o que está por trás disto.

Eu aposto que novos dispositivos demandarão interfaces cada vez mais ricas. Também aposto na web como uma plataforma cada vez mais presente. Por isso vejo com naturalidade uma tendência para investirmos cada vez mais em JavaScript e outros padrões web.

Nesse post vou falar um pouco de uma solução que implantei em um cliente. O Cenário lá é o seguinte: Eles possuem uma solution que contém mais de um projeto Web App e projetos WCF.

Nós já tínhamos implementado nesse projeto a Continuos Integration, criando uma Build Definition e setando a trigger de CI.

Depois de um tempo foi requisitado uma build noturna e que nessa build os projetos web e os serviços fossem publicados no ambiente de homologação, automatizando o processo de build e deploy.

Basicamente, iremos validar a compilação, rodar testes de unidade e integração (quando aplicável) e se tudo der certo, publicar no ambiente de homologação para que o usuário final pudesse validar as últimas alterações implementadas.

Para atender esse cenário, utilizamos uma funcionalidade do Visual Studio, o publish profile ( para infos sobre o que é e como criar, acesse o site: http://msdn.microsoft.com/en-us/library/dd465337.aspx )

Depois que criarmos os publishes profiles conseguiríamos publicar os sites e serviços se clicássemos com o botão direito e der o publish. Essa ainda não é a solução desejada.

Como fazer para encaixar isso na minha Build Definition e quando ela rodar os meus sites serem publicados?

Na sua Build Definition, vá na aba de processos e procure a opção MSBuild Arguments, conforme a figura abaixo:

Agora que a coisa começa a ficar interessante, o MSBuild tem um parâmetro que podemos passar que permite que eu informe o nome do meu Publish Profile para fazer o deploy logo após a compilação e execução dos testes.

Para isso digite o seguinte no MSbuild Arguments :

PublishProfile=”QA”

O “QA” é o nome que você deu para o seu publish profile. Para que todos os seus sites e serviços sejam publicados, basta dar o mesmo nome para o publish profile e tudo será publicado logo após a compilação e execução de testes.

Com isso, de forma simples e rápida montamos uma solução que compila e faz o deploy das nossas aplicações para qualquer ambiente que desejarmos.

Até a próxima.

Vejamos um exemplo:

Esquema

Classes POCO

Mapeamento

Note que a definição da associação many-to-one se dá pelo References no UsuarioMap, por default o Fluent NHibernate infere que a coluna que define a chave estrangeira seja Endereco_Id (nome da classe sendo referida + “_Id”). Assim como vimos anteriormente, podemos definir um nome diferente utilizando .Column("nome da colunda").

Feito isso podemos agora navegar a associação acessando a propriedade Endereco de Usuario:

Veja as queries executadas:

É interessante notar que a segunda query é executada apenas ao acessarmos a propriedade Endereco, por default as associações a outras entidades são carregadas sobre demanda (Lazy Loading), no futuro veremos estratégias de carregamento de associações e propriedades.

No próximo post: Associações one-to-many.

Semana passada eu estava fazendo uma PoC em floripa e acabou que pude ir em uma reunião do grupo DotNetFloripa para falar um pouco sobre o TFS.

A palestra era para ser de 45 mins, mas acabou que ficamos conversando bem mais tempo. Também, falar de TFS é fácil, posso ficar horas conversando sem problemas.

Para comeplementar, quem quiser pode baixar a máquina virtual que eu utilizei para realizar as demos no seguinte link:

http://blogs.msdn.com/b/briankel/archive/2011/09/16/visual-studio-11-application-lifecycle-management-virtual-machine-and-hands-on-labs-demo-scripts.aspx

Foi um prazer conversar com vocês !! Espero que na próxima eu consiga ir com mais calma e assim podermos beber mais cervejas!

Até a próxima!

Só que um cliente me mandou um backup do banco. Fui restaurar no LocalDb, lógico, nem tenho mais SQL Server Express instalado (não vem mais por padrão com o Visual Studio 2012). Qual não foi minha surpresa ao notar que ele não subia? Tive vários errinhos na janela de Restore do SQL Server Management Studio. Descobri que faltam alguns itens no registro do Windows. Basta colocá-los lá e tudo funciona. Eu podia ter feito via Transact-SQL, mas não sou um grande administrador do SQL Server, isso fica um pouco mais avançado do que tenho interesse de saber fazer. Nesse tipo de setup, no Windows, prefiro a janela.

Então fica pra referência. Se você precisar, os itens estão em HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQLE.LOCALDB\MSSQLServer. São os seguintes campos, todos string:

“DefaultData”=”<seu perfil>\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\v11.0″
“DefaultLog”=”<seu perfil>\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\v11.0″
“BackupDirectory”=”<qualquer diretório que exista, pode ser c:\temp>”

Onde está seu perfil, troque pelo caminho do seu perfil. Se seu user é giovanni, seria “C:\users\giovanni”.

Feito isso, basta clicar com o botão direito no banco no SQL Server Management Studio, daí Tasks, e escolher Restore > Database.