Tag: ThoughtWorks

Categories
Carreira

Você tem que ler os livros!

Nos últimos meses já ouví algumas pessoas dizerem que não têm costume de ler livros, ou questionarem a necessidade de lê-los, já que há uma abundância de fontes de leitura por aí na Internet.

Hoje em dia realmente temos milhares de formas de nos informarmos. Me lembro de ter lido em algum lugar que a Internet possui mais de 250 milhões de sites. Se somarmos isso tudo, realmente tem muita informação. Justamente por isso, faz parte da minha rotina diária dar uma navegada no Google Reader, onde tenho cadastrados os feeds de mais de 300 sites e blogs de diversos assuntos que acho interessantes. Essa é basicamente a minha principal fonte de informação diária e é a melhor maneira de me manter atualizado com tantas novidades surgindo por aí todo dia.

Porém, em alguns casos, para aprender e entender certos assuntos, você precisa ler os livros. Não tem jeito! Por exemplo, como é que um desenvolvedor de software pode dizer que entende Domain-Driven Design sem ter lido o livro do Eric Evans ou pelo menos o DDD Quickly? Ou então dizer que sabe sobre metodologias ágeis sem ter lido pelo menos um livro do Ken Schwaber, Kent Beck ou Uncle Bob? Como é que alguém pode se dizer Arquiteto de Software Sênior++ Certified ™ sem ter visto o Patterns of Enterprise Application Architecture e o GoF? Eu respondo: não tem como. Simplesmente não tem jeito, você precisa ler os livros.

Hoje mesmo o Patrick Kua, que trabalha na ThoughtWorks, escreveu um post sobre os livros que ele considera essenciais para saber sobre metodologias ágeis. Ele acredita que você precisa ler 11 livros, O.N.Z.E. livros, para entender sobre o assunto, e ainda completa: “Of course, simply reading the books won’t mean that you’re an expert […] though it’ll definitely help in providing context, advice or skills that you need to practice.”. Ou seja, mesmo lendo todos esses livros, ainda há muita coisa para aprender… E estamos falando sobre um assunto apenas.

Assim como os blogs e os sites, os livros são uma fonte de informação importantíssima e necessária. Se você quer trabalhar com tecnologia e desenvolvimento de software não tem jeito: tem que ler e ler muito!

Categories
Engenharia de software Eventos

[QCon 2007] Neal Ford: Building DSLs in Static and Dynamic Languages

QCon 2007 - Neal FordNeal Ford da ThoughtWorks fez mais uma apresentação sobre Domain Specific Languages, desta vez mostrando alguns aspectos do desenvolvimento de DSLs em linguagens com tipagem estática e dinâmica.

Ele evoluiu sobre a idéia de que uma DSL é um estilo declarativo de programação ao invés de imperativo. Um exemplo é a linguagem SQL. Em SQL você não diz como você quer alocar memória ou como organizar ponteiros e listas, você só diz o que quer e o banco de dados “descobre” como atender seu pedido.

DSLs podem ser usadas como uma camada de abstração sobre APIs, assim como Java poderia ser considerado uma camada de abstração sobre C, por exemplo. Veja os dois códigos a seguir que exemplificam esta diferença. O primeiro código é um código típico de API e o segundo código seria uma DSL wrapper para esta API:

// API
Car car = new CarImpl();
MarketingDescription desc = new MarketingDescriptionImpl();
desc.setType("Box");
desc.setSubType("Insulated");
desc.setAttribute("length", "50.5");
desc.setAttribute("ladder", "yes");
desc.setAttribute("lining type", "cork");
car.setDescription(desc);
 
// Fluent Interface
Car car = new Car.describedAs()
		.box()
		.length(12)
		.includes(Equipment.LADDER)
		.has(Lining.CORK);

A partir daí o Neal mostrou algumas técnicas para construir DSLs como aninhamento e encadeamento de métodos, finalizar/salvar “transações” e outras coisas mais. Também falou sobre as vantagens de se utilizar linguagens dinâmicas como Groovy e Ruby para tirar proveitos de features como closures, classes abertas, tipagem dinâmica e sintaxe menos rigorosa que a do Java.

Mais uma vez a questao dos testes foi enfatizada. Muito provavelmente as DSLs vão evoluir ao longo da vida do sistema e é necessário ter uma suite de testes verificando cada pequena parte e garantindo que os incrementos nela não trarão efeitos colaterais. Trabalhar com DSLs sem testes é um pesadelo!

Algumas coisas que você precisa ter em mente ao criar DSLs:

  • Pense sempre na DSL perfeita. Mesmo que você não consiga chegar na perfeição, pensar no melhor caso possível vai te ajudar a te guiar pelo melhor caminho. Neste caso utilizar uma técnica como TDD pode ajudar bastante pois você irá determinar onde quer chegar antes mesmo de começar a codificar.
  • Utilize um contexto pequeno. Não tente criar uma DSL super genérica, escreva um domínio especializado.

Download

Categories
Agile Fun

Being Agile is our favourite thing

Acabei de receber um e-mail do Carlos Villela com um vídeo muito bom da ThoughtWorks, empresa onde ele trabalha.

Não entendí muito bem se isso é um comercial (parece) ou se é só um vídeo aleatório. O caso é que eles pra variar mandaram muito bem e produziram o vídeo tosco mais legal dos últimos tempos, além de ser extremamente educativo! Confira e preste atenção na profundidade das palavras:

Categories
Integração Contínua Notícias

CruiseControl 2.7

Acabei de ler no blog da ThoughtWorks sobre o lançamento de uma nova versão do CruiseControl.

Esta versão é a primeira lançada depois do anúncio do CruiseControl Enterprise, eu pessoalmente estava com uma expectativa grande para ver os resultados práticos desta mudança.

Dentre várias melhorias, a mais legal delas foi o novo dashboard que possibilita que você saiba rapidamente o status dos builds do seu projeto, dentre outras informações. Além disso será possível desenvolver os seus próprios widgets e montar uma tela com todas as informações do projeto que você desejar!

Categories
Controle de qualidade

Testes com Selenium em vários browsers

Uma empresa chamada Reality QA criou um serviço interessante. Eles testam a sua aplicação web em vários browsers e sistemas operacionais diferentes utilizando como roteiro de teste um script Selenium. Os testes rodam automaticamente nas plataformas alvo e são gerados relatórios e screenshots dos testes na medida que eles vão acontecendo.

Para ver como funciona, veja o screencast produzido pela empresa.

Como essa ferramenta é beta eles ainda não cobram pelo serviço mas já tem um link de “Buy” preparado no site.

Hoje já é possível testar em vários browsers utilizando o Selenium Core só que você tem que fazer tudo manualmente (em cada browser que irá executar o teste você tem que abrir e executar o script na mão). Talvez eles tenham usado o Selenium Remote Control e criado proxies para várias plataformas diferentes.

Achei essa idéia interessante, vou estudar uma forma de fazer alguma coisa do tipo aqui para a empresa. Depois eu conto como foi.

Categories
Controle de qualidade Engenharia de software TDD

Qual é o percentual ideal de cobertura de testes?

Ontem estava tendo uma discussão com um amigo aqui do trabalho sobre cobertura de testes.

A nossa discussão começou quando eu fui mostrar para ele um teste de aceitação em Selenium que eu fiz para uma parte do sistema de gerenciamento de conteúdo da empresa.

Ele estava argumentando que acha que os testes de aceitação com Selenium não são tão interessantes porque eles são muito frágeis – alterações na interface podem quebrar os testes. Realmente isso pode acontecer. Mas se acontecer é só reescrever o teste, oras! Antes dele quebrar ele será executado várias vezes e só nisso várias horas preciosas podem ser economizadas.

Repare o seguinte: você efetivamente testará as telas do sistema navegando nele, incluindo, editando e removendo itens. Se este trabalho pode ser automatizado, porque não fazê-lo? Não é melhor gastar o seu tempo para elaborar novas táticas de testes e novos testes de outras partes do sistema ao invés de ficar navegando em todas as páginas “manualmente”?

Discussões deste tipo me fazem lembrar do manifesto Testivus, que dentre outras coisas prega que: “An imperfect test today is better than a perfect test someday” (Um teste imperfeito hoje é melhor do que um teste perfeito algum dia). Mesmo que os seus testes não sejam os melhores do mundo e que vez ou outra precisem ser corrigidos, é melhor tê-los do que não ter teste nenhum. Com o tempo a cultura de testes fica impregnada na equipe e os testes vão ficando cada vez melhores e mais numerosos.

É claro que eu não concordo que os testes possam ser um monte de lixo que não testam nada. Eu só acho que não se pode ter uma abordagem dogmática em relação aos testes. Se a sua aplicação tem 50% de cobertura de testes eu não acho isso ruim. Aliás, é BEM mais do que a maioria que existe por aí. Mesmo assim você pode (deve) testar bem mais.

Concluindo, eu particularmente gosto muito de utilizar a abordagem de desenvolvimento guiado por testes (TDD). Com TDD você tem uma cobertura de testes significativa já que os testes vão sendo escritos na medida que a aplicação é escrita. Porém se isso não puder ser feito por algum motivo, não acho correto estipular um percentual mínimo ideal de cobertura de testes. Só acho que deve-se testar muito e quanto mais, melhor.

Coincidentemente saiu ontem uma matéria no InfoQ sobre este mesmo assunto que vale apena a leitura.

Categories
Comunidade Mercado

E dá-lhe ThoughtWorks!

Os caras da ThoughtWorks se empolgaram! Não tem nem duas semanas que lançaram o Mingle e acabo de ficar sabendo de mais um, o CruiseControl Enterprise.

Eu acho que eles vão ganhar bastante dinheiro com os dois. E espero que eles ganhem mesmo porque os dois são muito bons. Só espero que eles não parem de produzir as coisas livres legais que sempre produziram (XStream, XFire, PicoContainer, etc) para passar a vender tudo! Bom, pelo menos na enterevista que eles deram no InfoQ disseram que o produto pago irá contribuir com a comunidade também, o que é bem legal. Se continuar assim está bom.