Posts Tagged ‘Java’

[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] 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.

Coordenando o RioJUG

Thursday, September 20th, 2007

Desde o início da semana sou o mais novo coordenador do RioJUG! Recebí um convite dos coordenadores atuais para ajudar na coordenação deste grupo, que é um dos maiores do Brasil. Com mais de 1000 usuários, o RioJUG é o grupo oficial de usuários de Java do Rio de Janeiro.

Vou trabalhar para levar novidades para a comunidade e vou me obrigar a fazer mais apresentações nas reuniões mensais! Já tenho alguns temas interessantes na cabeça. Em novembro pretendo apresentar algumas coisas que vou ver na Qcon. Vamos ver se vai dar tempo, senão fica para janeiro.

Uma coisa que também sinto falta é dos eventos. Ultimamente não teve um evento sequer que prestasse aqui no Rio de Janeiro. Vamos ver se conseguimos ressucitar o Rio Java Summit e criar mais oportunidades para trocarmos experiências! Quem sabe também não está na hora de rolar um coding dojo no Rio, a exemplo do que já tem feito o pessoal de Floripa?

Slides da palestra sobre TDD no RioJUG

Wednesday, June 20th, 2007

Estou disponibilizando os slides da palestra sobre Desenvolvimento Guiado por Testes apresentada no RioJUG no dia 19/06/2007.

Desenvolvimento Guiado Por Testes
View SlideShare presentation or Upload your own. (tags: tdd bdd)

Como o tempo ficou curto lá na palestra acabei não apresentando o último slide que contém alguns links interessantes para quem quiser conhecer mais sobre o assunto:

Otimização prematura

Friday, June 15th, 2007

Dando uma olhada em uns projetos que estavam no meu Eclipse encontrei um projeto antigo de uma empresa que eu trabalhei. Esse projeto teve o desenvolvimento mais curto da história: 1 dia! É sério, ele acabou no mesmo dia que começou por uma série de razões.

Mais isso foi só uma pequena introdução, a história de verdade não é essa. Dê uma analisada num trecho de código deste projeto que foi desenvolvido por alguém lá da equipe (detalhe: leia atentamente o comentário):

public class Usuario implements BussinessObjectModel {
 
    protected UsuarioDTO usuarioDTO;
 
    public void login() throws Exception {
        if(this.usuarioDTO == null || this.usuarioDTO.getSenha() == null || this.usuarioDTO.getUsuario() == null) {
            throw new Exception("Erro");
        }
 
        /**
         * TODO: codigo do login.
         * ir no banco de dados, decriptar a senha, comparar
         * com o cara. logar no JMS, mandar um SMS, atualizar
         * o cache de usuarios, fazer uma chamada ejb remota
         * dizendo que o usuario entrou.
         */
    }
}

Donald Knuth já dizia que a otimização prematura é a raiz de todo o mal. Mas acho que quando ele disse isso jamais imaginaria uma otimização TÃO prematura. Em toda a minha vida esse foi um dos maiores exemplos de overdesign que eu já ví!

Repare: era o primeiro dia do projeto. Nem sabíamos direito o que precisava ser feito e o cara já decidiu que a aplicação deveria ter DTOs, JMS, EJB e cache de usuários… Sem sequer pensar no problema o programador decidiu adicionar uma complexidade enorme e desnecessária ao sistema.

Quando se desenvolve um projeto de software, a primeira coisa que deve-se fazer é atender aos requisitos funcionais do cliente da forma mais simples e rápida possível. Em seguida faz-se refactoring do código para que ele seja melhorado e no futuro possa se adaptar melhor a eventuais mudanças. E só.

Isto significa que neste momento você não se preocupa com cache, por exemplo. Se por acaso algum dia houverem problemas de performance, aí sim, pensa-se em cache, distribuição da aplicação e etc. Neste caso esta aplicação estava prevista para ter pouco mais de 10 usuários simultâneos, uma quantidade de acessoss ridícula para se pensar em otimização.

Os desenvolvedores têm uma mania horrorosa de overdesign, especialmente os desenvolvedores Java. É preciso parar de tentar adivinhar o futuro e se concentrar mais nos problemas que precisam ser resolvidos agora. Deixe os problemas do futuro para serem resolvidos no futuro!

Palestra sobre TDD no RioJUG

Wednesday, June 6th, 2007

No dia 19/06 farei uma apresentação no RioJUG sobre TDD:

“Test Driven Development (Desenvolvimento Guiado por Testes) é a prática de escrever testes unitários de um software antes de escrever o código que está sendo testado. O TDD é uma prática utilizada em metodologias ágeis de desenvolvimento de software como o XP (eXtreme Programming). Esta palestra apresentará conceitos de TDD utilizando exemplos simples e de fácil entendimento. Serão apresentadas também suas vantagens, desvantagens e comparações com outros tipos de testes de software comumente utilizados.”

Para mais detalhes acesse a página do evento no site do RioJUG.

Apareçam por lá! :)

Testes com JUnit + HSQLDB

Thursday, May 17th, 2007

Hoje fiz uma experiência legal no projeto em que estou trabalhando.

Estou há um tempinho bolando uma forma razoável para testar a aplicação de cabo a rabo. A única coisa que eu ainda não estava convencido totalmente sobre como fazer era testar as classes DAO ou fazer testes envolvendo elas.

Já lí em alguns lugares algumas pessoas falando que os testes não devem utilizar o banco de dados por uma série de motivos e que os DAOs sempre devem ser mocks. Até eu mesmo já cheguei a questionar se isso é realmente necessário. Depois de um tempinho com a idéia fermentando na cabeça eu penso o seguinte:

Primeiro: É interessante testar os DAOs porque você precisa garantir por exemplo que todos os campos estão sendo lidos corretamente para os objetos e que as queries funcionam. No caso de utilização de JPA/Hibernate ainda te ajuda a validar se o mapeamento objeto-relacional está correto.

Segundo: Existem alguns tipos de testes que podem ser feitos na sua aplicação. Se falarmos de teste unitário eu concordo que não deve haver utilização de banco de dados mas sim mocks para os DAOs e tudo mais que não for objeto do teste em questão. Porém para testes de integração ou aceitação é desejável que o banco de dados seja incluído no teste já que faz parte da aplicação.

Mas o problema de envolver o BD nos testes é que eles (os testes) ficam muito lentos e isso desfavorece o desenvolvimento guiado por testes, que eu não vivo sem. Se os testes demoram eles são executados menos vezes e isso não é bom. Sem contar que se os dados do banco forem modificados os testes quebram. Argh!

Eis que surge o HSQLDB. O HSQLDB é um banco de dados escrito em Java puro, tem driver JDBC que funciona direitinho e entende comandos SQL com JOINs, GROUP BYs e praticamente tudo mais que você utiliza numa aplicação que utiliza o banco de dados de forma NORMAL (normal = não utiliza aquelas tosqueiras proprietárias do BD que depois que se usa não dá mais para trocar nem a versão do bicho!).

O que eu fiz foi fazer com que os testes se conectassem num HSQLDB ao invés do banco de dados de desenvolvimento. Para melhorar, esse HSQLDB não está nem rodando em modo server em lugar nenhum. Ele é iniciando junto com os testes e roda em memória na mesma JVM que os testes rodam.

Quais foram os ganhos obtidos com este approach:

1) Minhas queries agora estão sendo testadas, assim como a criação dos meus objetos pelos DAOs.

2) Os testes estão muito rápidos, nem parece que usam banco de dados! Eu tinha criado duas suites de testes, uma que tinha testes com BD e outra sem BD. Isso nem será mais necessário agora.

3) Agora eu tenho a garantia de que os dados de teste não serão modificados e com isso os testes não quebrarão mais por este motivo. Sabendo que os dados não mudarão posso fazer testes mais completos e elaborados.

Porém também experimentei alguns pontos negativos:

1) Qualquer alteração de modelo tem que ser refletida no script de startup do HSQLDB. O script de startup é necessário para indicar quais tabelas com quais campos e dados ele criará em memória. São CREATE TABLEs com duas ou três coisinhas a mais, muda pouca coisa.

2) Em algumas aplicações que eu trabalho tem lógica da query no hint!!! Isso acontece porque lá na empresa tem um trilhão de aplicações rodando em produção no mesmo Oracle que eu rodo minha aplicação. Sendo assim se eu faço uma query ferrada eu derrubo o banco e junto com ele uma boa parte da empresa. Para evitar que isso aconteça os DBAs otimizam uma boa parte das queries que fazemos, só que as vezes a coisa fica tão dramática que os DBAs têm que fazer MAGIAS no hint para a query executar num tempo razoável. Aí eles mexem tanto no hint que no final a query depende do hint para funcionar, quando o hint deveria ser só para ela ficar mais rápida. Aí fica assim: com o hint a query retorna o resultado de um jeito e sem hint de outro! Como hint é coisa do Oracle e o HSQLDB entende como comentário, eventualmente não será possível testar uma ou outra query porque no HSQLDB o resultado será retornado sem executar a lógica contida no raio do hint!

Vou evoluir mais em cima desta idéia e na medida que as coisas forem acontecendo eu posto aqui mais comentários.

Refatorando para aspectos

Thursday, May 10th, 2007

Acabo de assistir no InfoQ uma apresentação do Ramnivas Laddad sobre refatoração de aplicações para AOP.

Assistindo a explicação dele dá para entender a linha de raciocício que ele segue e a quantidade de possibilidades que a programação orientada a aspectos traz. Realmente é um saco fazer repetidamente código para controlar permissões, erros, transações, concorrência e outros mais. Com AOP a quantidade de esforço para implementar este tipo de situação é reduzida consideravelmente e este artigo trata exatamente disso: reconhecer trechos de código que são candidatos a serem reescritos para se tornarem aspectos.

Porém eu acho que deve-se tomar muito cuidado ao sair refatorando a sua aplicação para aspectos. Imagina um sistema com centenas de classes que possuem dezenas de aspectos diferentes. A impressão que eu tenho é que se você tem aspectos demais o sistema pode ficar até mais difícil de programar. Isto porque se você tem código fora do método sendo executado “dentro” do método, a clareza em relação ao que ele faz fica reduzida. Multiplique isso por centenas de classes e métodos e você tem um monstro indomável.

Mesmo assim a abordagem dele é bem interessante pois quando utilizada corretamente estimula a produção de CÓDIGO com lógica de negócio ao invés de código que não tem nada a ver com o que o sistema realmente faz, tornando o desenvolvimento mais produtivo.