Archive for November, 2007

[QCon 2007] Slides das apresentações

Wednesday, November 14th, 2007

Os slides de grande parte das apresentações da QCon 2007 foram liberados no endereço http://qcon.infoq.com/sanfrancisco/schedule/. Segundo a organização do evento em breve todos os slides estarão disponíveis lá!

Veja também o wiki e as fotos do evento, que continuarão sendo atualizados ao longo desta semana.

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

Tuesday, November 13th, 2007

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

[QCon 2007] Randy Shoup: The eBay Architecture

Friday, November 9th, 2007

QCon 2007 - Randy ShoupO Randy Shoup apresentou várias coisas impressionantes sobre o eBay. E quando eu digo impressionantes eu estou falando sério! Eu não fazia idéia do quão grande era o eBay e provavelmente ninguém que está lendo este texto faz. Então, eis alguns números para ajudar a entender melhor do que estamos falando:

  • 248 milhões de usuários registrados.
  • 1 bilhão de fotos.
  • $1812 dólares por segundo em transasções realizadas.
  • 100.000 linhas de código novas a cada duas semanas.
  • 44 bilhões de transações de banco de dados por dia.
  • 2 PetaBytes de dados.
  • 1.5 TeraBytes de logs por dia.

Enfim, é MUITA, muita coisa.

Para dar conta de toda essa infraestrutura monstruosamente grande a estratégia é até bem simples:

  • Particionar. Como você faz para comer um elefante? Simples: em pequenas mordidas de cada vez. As aplicações do eBay são divididas em 16.000 servidores de aplicação que utilizam mais de 1.000 instâncias de banco de dados em mais de 400 hosts.
  • Processamento assíncrono. Faça o máximo de processamento assíncrono possível, isso irá liberar a sua infraestrutura para atender as operações que necessariamente precisam ser resolvidas na hora.
  • Automação. Não perca tempo fazendo coisas que podem ser automáticas. Faça com que as rotinas de gerenciamento da infra sejam executadas automaticamente desde o momento que forem criadas. Automatize tudo que puder!
  • Lembre-se que tudo falha. Faça com que as falhas sejam detectadas automaticamente e quando uma falha for detectada faça alguma coisa sobre isso (automaticamente, claro). Tenha sempre um plano de recuperação de desastre e backup.

[QCon 2007] Ian Flint: Yahoo! Communities Architecture

Friday, November 9th, 2007

A palestra do Ian Flint sobre a arquitetura do Yahoo! foi bem interessante. É bem legal saber como esses caras grandes funcionam e fiquei bem surpreso com algumas coisas.

Qcon 2007 - Ian FlintA principal delas foi saber que eles usam Hibernate para persistência em aplicações Java. O mais impressionante é que essa aplicação tem em torno de 50.000 transações de banco de dados por segundo! Isso pra mim derruba totalmente aqueles mitos de que Hibernate não escala, que não é flexível e não funciona para softwares “grandes” e “sérios”. Se isso não é grande eu não sei mais o que é! Além disso eles usam um set de frameworks bem comum: Spring, C3P0, Log4J, etc.

Outra coisa interessante é que a grande maioria das aplicações deles é em PHP. Ele não disse o percentual ou a quantidade mas enfatizou bastante o fato de ser a maioria das aplicações então deve ser bastante coisa. Em segundo lugar eles usam mais Python e só depois vem o Java. Eles também têm várias aplicações de back-end e componentes em C e C++.

Em relação a banco de dados, eles usam na maioria das aplicações MySQL e em segundo lugar Oracle RAC. Inclusive o Ian disse que foi a primeira vez em toda sua carreira que ele viu esse Oracle RAC funcionar… Pelo visto ele já teve algumas experiências traumáticas…

Para finalizar, tenho percebido que assim como todo o resto das empresas que estão aqui (eBay, LinkedIn, Oracle, etc) eles simplesmente não inventam arquiteturas complexas como às vezes imaginamos. O segredo é uma arquitetura o mais simples possível!

Download

[QCon 2007] Eric Evans: Strategic Design

Friday, November 9th, 2007

O Eric Evans, autor do livro Domain-Driven Design, fez mais uma excelente apresentação entitulada “Strategic Design“. Dessa vez a apresentação foi sobre como implementar técnicas de Domain-Driven Design em projetos de software.

Qcon 2007 - Eric EvansSegundo o Eric, por conta do tamanho das equipes de software é impossível ter somente programadores excelentes. Isso faz com que nem todas as partes do um sistema sejam bem desenhadas, isso é fato. No entanto você pode fazer com que algumas partes do sistema sejam bem desenhadas e é essecial que isso seja feito no domínio da aplicação, que é o local onde está a complexidade crítica da maioria dos sistemas.

Uma coisa importante que ele frisou é que não pode existir um domínio corporativo usado por todas as aplicações (tipo “one ring to rule them all”), porque é impossível criar um domínio que atenda a todos os softwares. Cada aplicação deve ter o seu próprio domínio que deverá ser cuidadosamente projetado, dento de um contexto, para resolver os problemas que a alicação se propõe.

Algumas estratégias para implementar um bom domínio são:

  • Desenhe um mapa do contexto e sempre siga-o. Isso vai te ajudar a saber quais conceitos devem ser mapeados no seu domínio ou não e te impedir de perder o foco do sistema.
  • Trabalhe com os líderes do negócio para definir o domínio do sistema. E continue sempre trabalhando em conjunto com eles enquanto o domínio se especializa e evolui.
  • Crie uma plataforma que suporte trabalhar e evoluir o domínio. E mantenha esta plataforma protegendo o domínio.
  • Trabalhe com a gerência para ter liberdade de criação no contexto do domínio.
  • Desenvolva e modele o domínio. O domínio sempre evoluirá e será destilado ao longo da vida do software.

E como em toda a apresentação do Eric têm que acontecer alguma coisa estranha, tivemos um falso alarme de incêncio bem no meio da apresentação! O pessoal tomou um baita susto porque começou a tocar o alarme muito alto e a piscar um monte de luzes e todos tiveram que sair do hotel. No fim das contas era um alarme falso. Nunca mais jogo fumaça naqueles detectores!!! (hahahaha, isso obviamente é sacanagem, eu jamais faria isso… – eu teria acendido um isqueiro no detector de fogo e todos ficariam molhados, que é bem mais legal!)

Download

[QCon 2007] Cameron Purdy: The Top 10 Ways to Botch Enterprise Java Application Scalability and Reliability

Thursday, November 8th, 2007

QCon 2007 - Cameron Purdy: The Top 10 Ways to Botch Enterprise Java Application Scalability and ReliabilityCameron Purdy fez uma apresentação sobre as 10 melhores maneiras de estragar (isso mesmo) a arquitetura das suas aplicações Java! Foi surpreendente porque eu fui pra essa apresentação sem expectativa nenhuma mas ela foi ótima e muito engraçada!

A apresentação foi num estilo meio cômico e a cada slide várias pessoas foram se identificando com várias decisões de arquitetura patéticas que a gente vê por aí (eu inclusive já fiz e ví várias delas!).

Algum dos exemplos que ele deu que podem acabar com a escalabilidade e a confiabilidade de uma aplicação foram:

  • Estuprar o banco de dados: utilizar os recursos de banco para fazer coisas sem tanta importância como logar operações, guardar estado (session) ou guardar imagens.
  • Introduzir gargalos: qualquer coisa que milhares de requests têm que utilizar e que têm latência associada a carga.
  • Usar heaps gigantes na JVM: um FullGC de 10GB pode levar 3 segundos em laboratório mas em produção isso pode levar vários minutos travando completamente a aplicação.

E por aí vai…. Veja a apresentação completa (os slides estão bem legais por sinal).

Download

[QCon 2007] Cedric Beust e Alexandru Popescu: Designing for testability

Thursday, November 8th, 2007

Cedric Beust e Alexandru Popescu, criadores do framework de testes TestNG, fizeram uma apresentação entitulada “Designing for testability“.

QCon 2007 - Alexandru Popescu e Cedric BeustEles falaram algumas coisas interessantes sobre os “inimigos” da testabilidade como chamadas entranhadas à métodos estáticos, encapsulamento ao extremo (atributos private final) e cuidado com Singletons.

No geral a apresentação foi média mas acabou servindo para levantar um ponto importante.

Num determinado momento eles falaram claramente que não acreditam muito em Test-Driven Development porque ninguém nunca vai aplicar corretamente. Eles alegam que as pessoas não gostam de escrever código que dá erro de compilação e que fica “vermelho no Eclipse” para depois escrever código que funciona. Por isso eles na maioria das vezes não usam a técnica.

Eu acho que isso não é um problema do TDD mas um problema das IDEs! O que acontece é que com essas IDEs semi-automáticas de hoje em dia as pessoas ficaram muito acostumadas com o Ctrl+Enter e escrever o teste antes implica em não ter esse tipo de funcionalidade, o que pode dar uma falsa impressão de que você está fazendo algo estúpido. Sem contar que a feature “Build Automatically” faz com que o seu código fique assustadoramente vermelho quando a IDE tenta compilar o teste e não consegue… Se você programar em Ruby, por exemplo, essa falsa impressão desaparece. Quando você escrever um teste para um código que não existe, simplesmente o teste não vai funcionar. Nada de alarmes vermelhos na IDE. Enfim, para mim é uma questão de hábito. Coincidentemente numa das palestras seguintes o Charles Nutter falou exatamente sobre isso e concorda que o problema do TDD no Java são as IDEs.

Para finalizar sobre esse papo de TDD ou não-TDD, gosto muito daquele provérbio budista que diz: “vá sempre pelo caminho do meio“. Não acredito que todo mundo deva ser pragmático e sempre escrever todo e qualquer teste antes de programar absolutamente qualquer coisa. Ninguém vai morrer se você escrever testes junto com a implementação em certos casos. Para mim o que mais importa nisso tudo é o mindset de possibilitar que as dependências sejam isoladas, ter uma suite de testes decente para garantir qualidade/permitir refactorings seguros e coisas desse tipo.

Download

[QCon 2007] Wiki e fotos

Wednesday, November 7th, 2007

O Floyd Marinescu do InfoQ criou um wiki da conferência: http://qcon.editme.com. Durante o dia os materiais das palestras serão disponiilizados neste endereço.

Além disso eles criaram um grupo no Flickr onde serão colocadas as fotos do evento: http://flickr.com/groups/qconsf2007/. Como nem todas as pessoas estão cadastradas no grupo também é possível achar fotos procurando pela tag QConSF2007: http://flickr.com/search/?w=all&q=QconSF2007&m=tags.

[QCon 2007] Martin Fowler e Neal Ford: Domain Specific Languages

Wednesday, November 7th, 2007

Segundo dia de QCon e hoje foi a vez de Martin Fowler e Neal Ford falarem sobre Domain Specific Languages.

QCon 2007 - Martin Fowler - Domain Specific LanguagesCom dois profissionais desse nível dá pra imaginar como o tutorial foi espetacular! O Fowler é sem sombra de dúvidas o melhor palestrante que já tive a oportunidade de ver. O ritmo que ele impõe é sensacional e a paixão com que ele fala do assunto é contagiante!

Para melhorar ainda mais o dia começou com uma ótima notícia: o Fowler está escrevendo neste momento um novo livro sobre DSLs. O livro já está no forno há um ano e já tem muita coisa escrita. Toda a apresentação de hoje foi baseada no seu novo livro e inclusive tivemos acesso a todo o material da sua pesquisa e o primeiro draft do livro! Está sensacional! O Neal também está escrevendo um livro sobre Ruby e DSLs, porém pelo que eu entendí está num estágio bem menos avançado.

Como o material da apresentação fará parte desse novo livro a distribuição foi proibida. Já que não dá para colocar o material aqui vou falar resumidamente sobre os assuntos abordados durante o dia, que foi dividido em três grandes partes.

Na primeira parte os dois apresentaram um introdução sobre o que são DSLs e como elas podem ser úteis. Eles criaram um framework imaginário (uma máquina de estados) e começaram a mostrar todos os problemas de quando este framework é desenvolvido como uma API. Em seguida eles criaram uma “casca” em torno dessa API (uma Fluent Interface) para facilitar o uso da mesma.

A partir daí eles definiram os conceitos de DSL interna e externa. DSLs internas são como as Fluent Interfaces, que são escritas na linguagem do sistema (Java, por exemplo). DSLs externas são escritas em qualquer outra linguagem separada da linguagem do sistema e precisam de um compilador ou interpretador para serem executadas.

Os benefícios mais notáveis de construir DSLs são a melhoria na produtividade do desenvolvimento (porque o código da lógica de negócio é mais limpo e mais fácil de ser evoluído) e a melhoria na comunicação com os especialistas do domínio (porque as regras de negócio são escritas numa linguagem conhecida pelo especialista, facilitando o entendimento do código).

QCon 2007 - Neal Ford - Domain Specific LanguagesNo entanto também existem uma série de problemas. É necessário ter muito cuidado para criar um design bom que possa ser evoluído ao longo do tempo. DSLs algumas vezes são extremamente complicadas de serem implementadas mas o impacto é muito positivo. Um exemplo real pode ser visto em um post que fiz há algumas semanas sobre uma Fluent Interface que implementei em um projeto, que trouxe vários benefícios interessantes.

Uma das formas mais comuns de se criar DSLs é o padrão que eles chamaram de “Framework Out-Language In”, onde você começa com a construção de um framework e em seguida define uma DSL em volta dele (como um Façade). Utilizar técnicas de Domain-Driven Design pode ajudar bastante pois evoluindo a Ubiquitous Language você enriquece a comunicação/vocabulário do sistema, que fatalmente irá colaborar para a criação de DSLs mais ricas e que refletem melhor ainda o domínio.

Não é nem preciso dizer que eles bateram muito forte na questão dos testes. Como a programação de DSLs é complexa, é essencial testar muito bem cada pequena parte e variação possível! Além disso técnicas de Test-Driven Development certamente ajudarão a criar DSLs mais fáceis de serem usadas (porque se não for fácil de usar você fez alguma coisa errada).

Na segunda parte da apresentação o Neal Ford apresentou um tutorial prático de como criar DSLs internas em Java, Groovy e Ruby.

Essa apresentação foi bem mão-na-massa e ensinou várias técnicas para criação de DSLs internas. Ele mostrou vários exemplos utilizando encadeamento e aninhamento de métodos fazendo wrappers em coisas conhecidas como Log4J e java.util.Calendar.

Na terceira e última parte o Fowler apresentou um tutorial sobre como projetar e quais ferramentas podem ser utilizadas para a criação de DSLs externas. Essa apresentação foi bem mais teórica que a do Neal.

Ele mostrou como fazer para criar um parser de sintaxe, que consiste em um “lexer” (um tokenizador de texto), um parser (analisador sintático que organiza os tokens em uma árvore), um analisador semântico (que checa as regras de construção das frases) e a produção de alguma saída (que significa produzir qualquer coisa útil, como popular certos objetos e fazer certas operações).

Qcon 2007 - DSLDomain Specific Languages é uma técnica muito antiga. Muito antes do próprio Fowler começar a escrever e estudar sobre o assunto várias DSLs já existiam por aí (o melhor e mais clássico exemplo é a linguagem SQL utilizada em bancos de dados).

A opinião dos dois é que DSLs realmente prometem trazer várias melhorias no desenvolvimento de software, especiamente no que diz respeito a programação das regras de negócio e interação com os especialistas de domínio. No entanto eles acham que não existirá um dia em que os programadores serão desnecessários e que tudo será feito a base de DSLs, tampouco que este seja um assunto que terá um boom enorme e que mudará a vida de todo mundo. Eles acham que trata-se simplesmente de mais uma técnica útil para desenvolver software de qualidade.

[QCon 2007] Eric Evans: Domanin-Driven Design

Tuesday, November 6th, 2007

Qcon 2007 - Eric Evans - Domain-Driven DesignA apresentação do Eric Evans hoje sobre Domain-Driven Design foi excelente! A abertura do evento não poderia ter sido melhor!

Grande parte do que ele apresentou faz parte do seu livro sobre DDD, incluindo alguns dos exemplos usados no tutorial. Mas isso não fez com que as coisas ficassem menos interessantes. Muito pelo contrário, as discussões foram excelentes.

Falamos inicialmente sobre as características de um bom design de domínio. Na opinião do Eric um bom design é aquele que você consegue explicar para uma pessoa qualquer e ela entende mesmo não sendo especialista no negócio/domínio. Sobre codificação, o Eric falou que se interessa bastante pela clareza trazida por Fluent Interfaces, e DSLs internas e tenta usá-las sempre que possível pois aumenta muito a legibilidade do código. Além disso ele acredita que o uso de Behaviour-Driven Development é interessante no processo exploratório de um domínio e pode te ajudar a identificar e corrigir problemas de design.

Uma das frases que o Eric falou me lembrou a discussão que rolou na semana passada no GUJ sobre testes, TDD e etc: “Estamos no ano do Test-Driven Development e criar designs testáveis é essencial!”. Não quero acender novamente a discussão mas não posso deixar de dar a minha opinião nessa história. Realmente é inaceitável um software nos dias de hoje não ter uma suite de testes decente, não só pelos testes em sí mas por toda a influência positiva que isso traz no design do código, pela segurança que te dá para incluir novas funcionalidades e modificar existentes, segurança para corrigir bugs e tudo mais. Para mim é simplesmente impossível programar sem testes!

Guilherme Chapiewski e Eric EvansInfelizmente não consegui todo o material do curso porque o Eric utiliza esses materiais nos seus treinamentos e por isso não os disponibiliza publicamente. Mas eu consegui o Domain-Driven Design Pattern Summaries, que é um resumo de 39 páginas do livro dele com algumas coisas a mais. Achei bem interessante para se usar como referência. Esse resumo contém informações bem objetivas sobre todos os padrões apresentados no livro de DDD.

Além desse material o InfoQ disponibilizou a palestra Putting The Model To Work que foi uma das que o Eric apresentou para nós. Essa não foi exatamente a apresentação que tivemos mas foi bem parecida.

Para os leitores assíduos de blog, aí vai uma boa notícia: num dos intervalos eu perguntei para o Eric porque que ele não tinha um blog. Ele disse que ultimamente muitas pessoas têm feito essa pergunta e disse que está preparando alguma coisa nesse sentido. Perguntei sobre quando ele planeja lançar isso e ele disse que seria em breve! Com certeza será mais uma ótima fonte para leituras.

E para terminar, a gafe do dia: na hora do intervalo subitamente começamos a ouvir na sala vários barulhos estranhos de mictório e pia de banheiro… O Eric deu bobeira e foi no banheiro com o microfone sem fio ligado! Ao menos constatamos que o microfone era de boa qualidade porque o banheiro era meio longe, haha!