Archive for maio \25\UTC 2009

Nossas Impressões (André Pantalião e Rodrigo Ribeiro) – Falando em Java 2009

maio 25, 2009

Introdução

Neste  domingo, dia 24 de maio, acordamos cedo e perdemos a Fórmula 1(rs) por motivos nobres. Nós (André Pantalião, Rodrigo Ribeiro e Thiago Veiga) fomos ao Falando em Java 2009, evento organizado pela Caelum. O evento aconteceu no Espaço Hakka, localizado nas proximidades do metrô São Joaquim, com fácil acesso.

Report das palestras

Publicaremos posts com as nossas impressões sobre o evento:

Conclusão

Acredito que o evento tenha respondido as nossas expectativas, pois o conteúdo passado foi muito bom, fora o conhecimento dos palestrantes. O número de inscritos para esse ano, por volta de 500 pessoas, só resume o interesse da comunidade Java e a busca por novas tecnologias e know-how na área de atuação.

Pontos positivos

  • O pessoal do evento foi bastante prestativo;
  • 3 “coffee-breaks” de ótimo nível;
  • Sorteio de livros, canecas, camisas e um Nintendo Wii (!!!)para o público ( Rodrigo Ribeiro ganhou uma camisa da Red Hat 🙂 );

Pontos negativos

  • A cada fim de palestra era permitido a saída dos congressistas para um café. Com isso os congressistas perdiam o foco, criava-se aquela multidão e sempre havia um atraso adicional para o começo das apresentações;
  • Alguns palestrantes perderam o foco durante as apresentações, ou não conseguiram passar todo conteúdo presente nelas por falta de controle de tempo. Isso com certeza pode ser melhorado para o futuro.

Espero que vocês, caros leitores, possam apreciar a leitura das nossas impressões, coletadas durante o evento. Fiquem à vontade para comentar, criticar ou complementar.

Anúncios

Palestra: Abertura do Evento – Falando em Java 2009

maio 25, 2009

Abertura do Evento

Palestra apresentada por Fabio Kung e Sergio Lopes

Fabio Kung e Sergio Lopes abordaram o histórico do evento Falando em Java e sobre a história da Caelum.. O evento começou em 2007, com 210 pessoas. Em 2008 tinha 330 pessoas e neste ano a perspectiva era de 500 pessoas.

A Caelum começou com 2 pessoas em 2004 e hoje eles tem 60 pessoas. Falaram sobre a união da equipe, sobre vestir a camisa e sobre como a empresa funciona. Assim como na Voice, muitos dos funcionários da Caelum iniciaram sem saber programar, apresentando um bom avanço no crescimento profissional e pessoal.

Apresentaram alguns novos cursos ( a serem lançados ) como Lógica de Programação, TV Digital e criação de interfaces web com Adobe Flex.

Seguindo a linha de notícias da Caelum falaram sobre uma nova unidade em Brasília e uma atual no Rio de Janeiro. Haverá o lançamento de um livro sobre Arquitetura e Design de Software (previsão: NOV/2009); maiores informações em: arquiteturajava.com.br.

Confirmaram a ausência de Bill Burke no evento, porque ele não conseguiu tirar o visto para o Brasil, após 3 tentativas. A palestra do Bill foi substituída por uma palestra do Jim Webber.

Poderiam ter sido mais sucintos e ter a palestra um pouco mais organizada. Sei que é necessário fazer propaganda, mas foi meio cansativo.

Palestra: Guerrilla SOA – Falando em Java 2009

maio 25, 2009

Guerrilla SOA

palestra de Dr. Jim Webber da ThoughtWorks

Foi uma palestra muito bacana, abordando de forma direta e engraçada um assunto que normalmente traz mais perguntas do que respostas.

Muitas vezes ele encontra muitos sistemas complexos e nestes casos eles utilizam middlewares. Mas ele vai mostrar uma outra opção que utiliza:

  • Agile: pode ser usado em aplicacoes grandes.
  • Web:  Não da forma que conhecemos.

Podemos trazer agile e web juntos

No começo da computação

No começo da computação era comum e normal ter “silos” de aplicações.  Algumas pessoas inteligentes, presenciando esse panorama, enxergaram a possibilidade de dividir e comunicar estes silos de aplicação. Estes caras fizeram muito “encanamento” para juntar estas aplicações.  E isto funcionava, porque de alguma forma os silos estavam ligados entre si. Não era bonito mas funcionava.

Através dos anos, com o desenvolvimento da computação, a competição surgiu e os especialistas de integração se tornaram muito fortes. Eles exercerciam muita influência e se tornaram muito grandes no mercado.

Eles absorveram muita coisa: BPM, Regras de negócio, adapters, GUI tools, segurança, transformations, confiabilidade…. Com isso, mais silos foram integrados e, mesmo assim, não se tornaram muito melhores.

Neste cenário, SOA veio ao resgate destes problemas. Veio para aumentar o nível de abstração, para pensarmos em nosso sistema com uma mente voltada ao negócio. Mas não é para ser implementado da forma que os livros pregam, não focam em processos de negócio, mas em uma visão de TI.

ESB poderia ser uma boa opção, mas ele é ingovernável, porque para ser efetivo todos os sistemas da empresa deveriam estar funcionando no mesmo bus. E se tivéssemos este bus, estaríamos replicando o problema que atualmente temos com os DBAs.  Além disso, esta solução não escala.

Pensando em agilidade

Ninguém pode negar a beleza do modelo tradicional. É mais confortável, parece que podemos prever tudo. Mas, sabendo que não podemos prever tudo, aprendemos ao longo do projeto. Por isso muitos projetos waterfall falharam.

Foi abordada a criação do manifesto ágil, e que os valores ágeis são bem diferentes do tradicional. E que para eles funcionarem tivemos que aprender sobre BDD, restrospectiva, TDD, review e outras técnicas. Aprendemos também a crescer de forma incremental. E temos que fazer isto para desenvolvimento de sistemas complexos e não só para uma única aplicação.

A WEB

A web quebrou regras. Não foi só uma plataforma de publicação, mas de coordenação de tarefas. Quando navegamos em um site como o Amazon, vamos tela a tela… sendo guiados no processo de compras.

A web é protocol-centric, fazendo com que não seja necessário nenhum middleware. É uma rede “burra”, mas que é uma boa idéia.

A rede telefônica é boa em comprar e prover serviços de voz. Quando tentamos utilizar para serviços de dados, chegamos a um limite. A internet é a rede mais burra possível, ela roteia os pacotes independente do que esteja sendo executado.

Tem uma arquitetura que permite o surgimento de inovação, sem que haja previsão do quão grande isso será.

SOA Tradicional

Formada por pessoas de gabinete e programadores no front.

A guerrilha SOA propõe a idéia de quebrar em diversos pequenos passos, como parte de um grande programa de mudança. Devemos dividir os serviços de acordo com os serviços de negócio, deixando com que os responsaveis do negócio definam e sejam responsáveis  por ele.

Devemos priorizar e entregar incrementalmente os serviços, assim damos valor ao trabalho daqueles que estão no gabinete e os que estão no front.

Web e Serviços

A web é um middleware. Ele gastou muito tempo trabalhando em soluções de middleware. E só depois percebeu que a web já fazia quase tudo. E além disso, a Web já está em todos os lugares.

Além disso, a web é incremental, porque podemos fazer deploy de coisas novas sem quebrar o que já existe. Fazendo com que o risco de usar a web seja muito baixo.

O middleware, neste cenário, é opcional. A web pode ser o seu ESB. Se precisar escalar, coloque um servidor proxy para sua aplicação. A Web é projetada para crescer.

As vantagens da tecnologias Web-Centric em comparação da abordagem tradicional:

  • evolutionary design (ao contrario do BDUF)
  • entrega constante (grandes projetos)
  • Mais barato (caro)
  • Incremental (arriscado)
  • Escala da internet (escala da empresa)
  • Tem em todos os lugares (especializada)
  • integração por produto, entregando valor para o produto

Blog:  http://jim.webber.name

Alexandre Gomes, da Sea, fez uma palestra sobre este assunto no lançamento do InfoQ Brasil.

Perguntas que foram feitas

Se SOA é ruim, porque falamos dela tanto?

– Muita gente faz dinheiro com ela.

– Queremos que SOA funcione.

Como usar HTTP para nossos serviços?

– Fornecer os serviços no lado do servidor.

– Implementar melhor máquina de estados no lado do cliente, aprendendo novas técnicas ou reaprendendo técnicas tradicionais.

Quando eu utilizaria SOA dentro de uma empresa?

– Nas mesmas situações que você utilizaria lits distribuídos hoje. usar distribuído por default, REST.

– No ano passado estava trabalhando para uma empresa no Canadá e perceberam que podiam cachear uma boa parte do catálogo utilizando REST. Desde então, ele usa como REST por default. Só não utilizaria em situações onde o tempo de latência deve ser inferior a 1 segundo. neste caso, ele pagaria por isso.

E a TV Digital?

Ele acha que está convergindo com a web, será um aliado natural da Web.

Palestra: O profissional Java Efetivo – Falando em Java 2009

maio 25, 2009

O profissional Java Efetivo

Palestra ministrada por Paulo Silveira e Rafael Cosentino

Como adquirir conhecimento para ser um profissional de destaque?

Fizeram uma palestra que tentou ser engraçada. Tentaram criar uma história para embasar a apresentação, mas boa parte da platéia não “embarcou” junto com esta história.

Foram apresentados alguns problemas e apresentada a melhor solução para eles. A idéia era boa, mas no fim das contas, falou-se muito do personagem de exemplo: Nico. E o conteúdo foi pouco.

Como foi bem levantado por @lucastex no Twitter:

lucastex: #falandoemjava muito #nico e pouco conteudo na palestra… Sorry, deve ter mais sentido pra quem conhece o nico

Arquivo texto

A primeira solução proposta foi um arquivo texto com um formato específico para ser enviado aos fins de semana. Soluciona o problema de integração entre aplicações feitas em linguagens diferentes. Como é uma transferência de arquivo, usa-se TCP/IP+FTP+um formato específico para o arquivo texto.

Pontos positivos:

  • Simples;
  • Independente de plataforma;
  • Perfomance devido a pouco código escrito.

Pontos negativos:

  • Escalabilidade;
  • Segurança;
  • Manutenção.

Aprendizado: alternativa encontrada no trabalho. Solução “forçada” para a situação.

Integração utilizando protocolos binários

O exemplo dado foi de um sistema de cirugia/operação a distância (remota). Ao invés de usar WebServices (SOAP, XML, HTTP e TCP/IP), que pode resultar em lentidão, é melhor usar protocolos binários (UDP / TCP/IP).

Pontos positivos:

  • Performance.

Pontos negativos:

  • Manutenção;
  • Complexidade.

Aprendizado: Universidades, onde os professores forçam o conhecimento com performance.

Integração utilizando SOAP / WSDL

O foco foi criar uma solução que atendesse um sistema de integração de guias de saúde de pacientes no Brasil. Como o objetivo era padronizar, foi escolhido o SOAP/WSDL.

Pontos positivos:

  • Padronização;
  • XML;
  • HTTP;
  • Integridade;
  • Burocracia.

Pontos negativos:

Aprendizado: Comunidade Java (GUJ), fatos do cotidiano como padronização da Nota Fiscal Eletrônica Nacional (SOAP/WSDL).

Integração utilizando Mashup

O browser faz requisições a serviços diferentes e concentra em um local só.  Neste caso, para facilitar, ao invés do SOAP e XML, utilizamos algo mais simples, leve e fácil de ler. Pode ser aplicado para solucionar problema de localização de venda de comida (Chinese Food), centralizando as informações via Google Maps.

Pontos positivos:

  • Fácil de ler e debugar;
  • Simples;
  • Leve;
  • Mais pragmático;
  • no caso de JSON: browser é cliente.

Pontos negativos:

  • Falta formalização;
  • Estilos diferentes.

Integração por troca de mensagem

Pode ser aplicada no sistema de integração do Detran no Brasil. Havia antiga lenda que se você tomasse multa em outro estado que não fosse o de origem do seu carro a multa não chegaria para você pagar. A sugestão é a troca de mensagens com centralização.

Pontos positivos:

Pontos negativos:

  • Performance;
  • Complexidade.

Aprendizado: literatura (Livros técnicos, “bíblias”).

Conclusão

Existem várias formas de adquirir conhecimento portanto é necessário estar “antenado” a tudo o que se passa e a comunidade é onde você pode ter acesso a diversos tipos de informação.

Palestra: Seam e Web Beans – Falando em Java 2009

maio 25, 2009

Jboss Seam e Web Beans

Palestra ministrada por Alessandro Lazarotti (Red Hat) e Ricardo Nakamura (Caelum)

Alessandro e Ricardo mostraram como o Jboss Seam e WebBeans se relacionam entre si e qual o futuro de ambos. Foi usado, como exemplo, a rotina diária do Ricardo Nakamura.

O assunto pode até não ser novo, mas fizeram a apresentação com muita competência. O Ricardo foi engraçado e apresentou o que se propôs. Fez também uma conceituação legal de inversão de dependência. O problema foi a falta do controle de tempo, que impediu que todo conteúdo previsto fosse passado.

A parte de conceituação do ricardo foi muito boa!

Ele usou como exemplo a sua rotina diária:

Processo Normal:

  • Acorda
  • Vai ao banheiro
  • Troca de Roupa
  • Vai comprar pão
  • Toma café da manhã
  • Sai para trabalhar

Sair para comprar pão, para ele, é um processo muito chato. Ao invés de comprar pão, ele queria uma solução um pouco melhor. As alternativas seriam:

  • Sair de casa e comprar o pão
  • O pão ser entregue em casa
  • Comer para quê?

Inversão de controle

Ir comprar o pão é ruim. Porque não inverter o controle ? Mas o que vai ser invertido? Vou fazer o pão? o pão vai me comprar ? A frase não está clara.

Que aspecto do controle está sendo invertido?

Recursos, dependências de alguém (algo). O pão para mim é muito importante. Então teremos que fazer injeção de dependências (DI): o pão será injetado na casa.

Existem alguns frameworks, muito falados, que fazem a injeçào de dependência, como o Spring, Pico Container, Guice e outros.

Expandindo a idéia

Quero também receber água em casa. Como fazer isso?

  • Ligar na fornecedora, verificar se entregam em casa, combinar pagamento.
  • Avisar portaria e empregada.

Estes passos se repetiriam para outros itens que eu desejasse receber em casa. Não seria bom se esta configuração fosse sempre padronizada ?

É preciso haver padronização com frameworks, recursos e configurações. Logo, foi criada a especificação JSR 299 (Contexts and Dependency Injection for java EE), que padroniza a injeção de dependências e gerenciamento do ciclo de vida contextual.

A especificação (CDI)então tomou forma e está próxima de sua proposta final. Mas, qual a implementação de referência da CDI (especificação JSR 299)?

Web Beans é a implementação de referência. Mas então o que é o Seam Framework?

Ele surgiu junto com a especificação, mas não tem vínculo com a especificação. A especificação nasceu com base no Seam. O Seam foi a inspiração. No futuro, o Web Beans será o core do JBoss Seam.

Web Beans

Mostou um pouco de código, baseado no exemplo da entrega de pão em casa.

  • Mostrou o funcionamento do WebBeans com Java SE.
  • Depois com JSF.

Seam

Muito do que foi mostrado é igual ao Web Beans. Mas o Seam não é só isso. Ele suporta muitas outras funcionalidades. É uma plataforma muito grande de integração, para que você não tenha que ter diversos frameworks de integração.

Mostrou exemplos de uso do Seam na apresentação, tais como: envio fácil de e-mail, extensões para o JSF, annotations, expressions language, etc.

Seam 3

As novidades serão:

  • Web Beans como engine;
  • Integrador de diversas tecnologias;
  • Ferramentas de utilidade: plugins, seam-gen, maven;

A mensagem final foi: o Seam não é anarquia, não força você a escrever o projeto da forma dele.

Palestra: VRaptor3: Guerrilha Web – Falando em Java 2009

maio 25, 2009

VRaptor3: Guerrilha Web

Palestra apresentada por Felipe Sabella e Guilherme Silveira (Caelum)

Esta palestra foi uma apresentação (no fundo, uma mensagem de “Use-me”…) das novidades do VRaptor3, framework de aplicações Web desenvolvido pelo pessoal da Caelum, que ainda está em fase de testes e sem documentação completa, tendo sua liberação para o público programada daquia a 3 semanas (previsão dos palestrantes).

Começo

Tudo começou em 2004, quando o pessoal da Caelum buscava uma alternativa mais completa para criar a interface do “GUJ 2.0″, pois o framework usado no momento, o WebWorks, não estava satisfazendo as necessidades. Partindo da premissa do “Quer algo do seu jeito, então faça você” ou “É uma porcaria, vamos fazer o nosso”, surgiu o projeto VRaptor.

Projeto VRaptor

VRaptor como foi dito, não veio pra “reinventar a roda”, mas para facilitar o desenvolvimento Web com a maior compleitude possível. Foi usada a frase “Quando se rouba idéias de todo mundo é uma pesquisa”, para embasar o desenvolvimento da ferramenta e a busca para agregar as necessidades principais do programador Web.

Em uma pesquisa rápida a platéia foi questionada sobre quantos projetos deram certo com Struts e quantos falharam (a mesma coisa com JSF). Algumas pessoas levantaram a mão para certo, outras para errado, mas no final o objetivo era dizer que com o VRaptor as coisas seriam diferentes (“Jabá” da ferramenta, é claro). Foi possível ver que o auditório estava bem fracionando sobre frameworks já usados em desenvolvimento Web, citando até outros exemplos. Hoje no mercado temos cerca de 120 frameworks de desenvolvimento Web disponíveis, aumentando e muito as opções de uso.

Novidades da versão 3

Foram apresentadas as seguintes novidades da versão 3 do VRaptor:

  • Integra com Spring e Pico Container por padrão (Spring é default);
  • Cria novas integrações DWR e Flex;
  • Refactor amigável: validação e redirecionamento;
  • VRaptor auxilia nas annotations do RESTful;
  • Features “legais”: upload e download de arquivos com menos linha de código;
  • URI’s mais limpas e claras (inspiração no Rails);
  • Definições de escopo (uso da annotation “@ApplicationScoped”);
  • Delega para outros a configuração de XML e properties;
  • Conventionful (totalmente convencionável): retorno de método para os mais diversos tipos & collections.

Durante a exposição de cada uma das novidades ambos os palestrantes mostravam, compilavam e explicavam códigos com uso da ferramenta, tornando bem claro o entendimento de uso da mesma.

Por que usar VRaptor?

  • Há pessoas que não gostam de Struts Action (gosto pessoal dos dois e de outras pessoas. Dizem que cada vez que se usa Struts Action “mata-se uma foca”);
  • Cada framework agrada tipos diferentes de usuários. VRaptor pode agradar você.

No final (tirando o “jabá” de sempre) foi uma palestra para agregar conhecimento de mais um framework Web, que pode ou não nos agradar, mas que já tem aceitação de um certo número de pessoas. Ambos os palestrantes conseguiram expor ao público de maneira clara, dinâmica e concisa os conceitos passados.

Palestra: Arquitetura para aplicações Java de médio porte – Falando em Java 2009

maio 25, 2009

Arquitetura para aplicações Java de médio porte

Palestra apresentada por Guilherme Moreira e Sergio Lopes (Caelum)

A palestra teve como foco o crescimento de sites ou aplicações Web, que ocorrendo de forma desordenada e sem planejamento tendem a gerar downtime, timeouts de resposta, inconsistência de dados, etc. Com isso perde-se dinheiro; as vezes muito dinheiro. Tendo como base esses tipos de aplicações os palestrantes abordaram problemas passíves de ocorrer, análise e as possíveis soluções a serem tomadas.

Problema 1: SOAP e gargalo de Rede

  • JSON x XML x WSDL (podem gerar problemas de tamanho de arquivo e compactação).

Solução: Uso do Fast Infoset (FI), que compacta XML (em até 30%) e tem performance.

Problema 2: Hibernate não otimizado

  • Banco de Dados é o gargalo (famosa primeira conclusão).

Solução:

  • Conhecer o cache de primeiro nível e evitar de carregar muitos objetos na memória (risco dejava.lang.OutOfMemoryError: Java heap space”);
  • Aprender a usar “stateless session“.
  • Cuidado com o “n+1 selects“;
  • Aprenda a usar as configurações certas do Hibernate (“@BatchSize“, por exemplo).

Problema 3: BD sobrecarregado

Solução:

  • Abrir conexões somente quando for necessário;
  • Use pool para reaproveitar conexões entre requests;
  • Só inicie transações quando for necessário;
  • Evite o uso do BD o tempo todo;
  • Use cache!

Problema 4: indisponibilidade

Solução:

  • Uso de cluster. Vantagens: escalabilidade e disponibilidade. Desvantagens: performance e não-simplicidade;
  • Uso de load balance. Vantagens e Desvantagens idênticas ao caso do cluster;
  • Gerenciar estados do cluster: Sticky Sessions (caiu a sessão, acabou), replicação (manda os dados para outra máquina) ou stateless (s/ estado nenhum. “Pra que estado?…rs”).

Após as apresentações dos “problemas-análise-solução” ambos palestrantes colocaram a prova e ao vivo uma demo de máquinas em cluster e load balance usando JBoss. Resultado : FAIL! Isso provou que mesmo tendo experiência no assunto, preparando anteriormente a demo, usando bons micros e outros poréns, é certo que algo pode ocorrer e que outros fatores podem influenciar.

Outras idéias para análise de arquiteturas:

Para finalizar eles deixaram uma frase de Martin Fowler para pensar: “Primeira Lei do Design de distribuição de objetos: Não distribua seus objetos” (Nem sempre o gargalo é a rede…).

É importante ressaltar novamente que na palestra houve a apresentação de códigos conforme os exemplos foram passados. Isso facilitou e muito o entendimento do público (tirando a falha na apresentação do cluster).

Palestra: Para onde vai a plataforma Java? – Falando em Java 2009

maio 25, 2009

Para onde vai a plataforma Java? Linguages dinâmicas, JavaTV, JavaFX e além!

Palestra apresentada por Anderson Leite e Fabio Kung

Basicamente tivemos como carro chefe da apresentação as novidades do Java 7 e Java 8. Eis abaixo elas:

Java 7

Está muito incerto quais as features que irão realmente sair, e muita coisa que ia sair não vai mais. A nova versão passa por um processo muito demorado e burocrático. Sua previsão de lançamento (JDK) é em Janeiro de 2010. Os palestrantes fizeram uma breve pesquisa com os participantes do evento e constataram que só um quinto usam Java 6. Se a maioria não está usando Java 6, porque  pensar em usar o Java 7 (fora que o Java 5 é muito usado também)? Essas tendências para o  futuro só o futuro dirá se surtirão efeito.

Polarização de Plataformas

Kung acredita que ocorrerá uma polarização entre plataformas, não entre linguagens. Várias linguagens serão executadas sobre a plataforma .NET ou plataforma Java. A Microsoft saiu na frente com o Java e a Sun correu atrás, meio atrasada com o MLVM (Da Vinci Machine). No final, o objetivo é tornar a plataforma a melhor “hospedeira” para outras linguagens, não só a nativa.

Novidades do Java 7

Kung e Anderson mostraram exemplos em código estático acerca das principais características da versão (Para detalhes mais técnicos da especificação, vide  Alex Miller e Peter Ahé):

  • Meta Object Protocol;
  • Fast Interfaces;
  • Tuple Signatures;
  • Method Handles;
  • Invoke Dynamic;
  • Interface Dynamic;
  • Anonymous Classes;
  • Interface Injection;
  • Tail Class.

Como a JVM é bastante dinâmica e só a pouco tempo viu-se o “poder de aceitação” para outras linguagens que ela tem, será questão de tempo para a plataforma se adaptar a essa realidade. Por isso o projeto do MLVC é pretensão real para a versão 7. Um exemplo é o uso do Invoke Dynamic: a JVM executa o código, faz uma requisição ao target para saber em qual linguagem compilar (JRuby, Jython, etc.) e executa. Tal qual o Java, após a primeira execução a velocidade de qualquer código é praticamente a mesma de um código Java executado. Outra novidade será o JigSaw (descrito pelas JSR294 e JSR277), que tem como idéia versionar arquivos .jar (ainda é dúvida se entra para a versão 7). E por último o G1, o Garbage First (novo Garbage Collector), que agora não será mais definido por regiões estáticas, mas por regiões dinâmicas e poderá ter o tempo de passagem de coleta de lixo definido pelo usuário.

Java 8

Closures (não confundir com Clojure, a linguagem de programação), idéia para a versão 8, ainda está sendo discutida em termos de padrão, mas a idéia principal (inspirada em Ruby) é rodar “pedaços de código” dentro de um “código completo”. No momento temos 3 propostas para padrão a ser seguido:

  • BGGA;
  • CICE (Google por trás deste estilo de padrão);
  • FCM.

Outras novidades para esta versão são:

  • Switchs poderão aceitar strings;
  • JavaBean Property: suporte a Getters e Setters automáticos na criação de atributos;
  • BigDecimal Operator Support: novo literal pra BigDecimal (ex: 10n) e suporte a sobrecarga de operadores.

JavaTV, JavaFX e além?

Devido a tomarem grande parte da palestra com exemplos e futuro da plataforma Java, os termos que perfaziam o final do título da apresentação foram pouco abordados. Sobre JavaTV foi apenas mostrado o diagrama do Ginga e dito que há grande potencial para os desenvolvedores e grandes players para a TV Digital no Brasil. E no caso do JavaFX é que a onda das aplicações RIA e clients gordos (usando Adobe Flex, Silverlight e outros) está em alta. Como diria o poeta e colega nosso Fabrício Campos: choveram no molhado na parte final da apresentação, e não conseguiram dar por completo o foco da palestra.

Eles indicaram para leitura um artigo da Mozilla: “Introduction to JavaScript” (outro link do mesmo assunto).

Palestra: WebServices RESTful – Falando em Java 2009

maio 25, 2009

WebServices RESTful

Palestra apresentada por Jim Webber (ThoughtWorks)

Introdução

Jim, que na minha opinião, foi o melhor palestrante do evento, fechou o evento falando do mesmo assunto que seria destinado a Bill Burke, WebServices RESTful. Após apresentar sua MiniBio ele apresentou os tópicos da apresentação:

  • The Richardson Maturity Model;
  • Web Architecture;
  • Tunneling and POX;
  • URI templates and CRUD Services;
  • Hypermedia Formats;
  • RESTful Services.

The Richardson Maturity Model

O modelo de maturidade Richardson é definido em quatro níveis:

  • Level 0: SOAP, XML, RPC, POX (single URI);
  • Level 1: URI tunneling (muitas URI’s, único verbo);
  • Level 2: Muitas URI’s, muitos verbos (CRUD Services – Modelo Amazon S3);
  • Level 3: Level 2 + Hypermedia (RESTful Services).

Web Architecture

  • Conceito Web: baseada em recursos, acessada por URI’s (nunca diga URL’s: Deus mata crianças e gatos se você fizer isso, de acordo com Jim), arquivada em meios físicos, acessada por meios lógicos (WebServices) e distribuída para aplicações finais (usuários). Tudo é baseado em verbos HTTP;
  • Tudo é acessado via URI’s. URI é um endereço de acesso a recurso(s) de sistema(s);
  • A Web é muito poderosa: é escalável, tolerante a falhas, recuperável, tem baixo acoplamento, interface uniforme, modelo stateless e fail-over fácil;
  • HTTPS é uma tecnologia madura (baseada em SSL) e deve ser aplicada na Web;
  • Web != REST  (não abuse da Web).

Tunneling and POX

  • URI tunneling Pattern: URI’s com assinatura padrão e facilidade de manutenção, acesso e mapeamento;
  • URI tunneling Strengths: muito fácil entendimento e usabilidade em outras linguagens;
  • POX Pattern: como “parsear” padrões de texto, processá-los e disponibilizar as informações de envio;
  • POX Strenghts: simples, apenas usa HTTP POST e XML, facilidade de reuso, sem suporte a metadados;

URI templates and CRUD Services

  • Web já detém a maioria dos recursos. Deve-se usar o CRUD e pensar nele como base (Jim apresentou exemplos de sinalização de mensagens usando GET, POST, PUT, DELETE);
  • CRUD é bom? Sim, mas CRUD não é REST. Modelo CRUD ainda é muito implementado para armazenar dados somente.

Hypermedia Formats & RESTful Services

  • Microformatos na semântica W3C;
  • RESTful services é o level 3 (media type rules!). Logo é preciso implementar formatos hypermedia e XML (e/ou Application XML) não pode conter links. Do contrário não é nível 3;
  • Application /vnd.restbucks + XML: é o formato XML para hypermedia; não é padrão para a IANA;
  • Links descrevem protocolos, fluxo, regra de negócio. Logo podemos pensar em “Link as API” e tudo como framework;
  • Se você não tem hypermidia você não tem o RESTful;
  • Use a Web para escalabilidade massiva, mas com tolerância;
  • HTTP tem estados e header para todas as situações. Queremos ter baixo acoplamento e isso pode ser auxiliado por meio dos links hypermidia.

Para finalizar Jim Webber deixou um link de um artigo seu escrito para o InfoQ, contendo os mesmos exemplos da apresentação. Agradeceu a recepção e o interesse do público brasileiro. Da minha parte fica a impressão de quão incrível são os palestrantes internacionais e a desenvoltura para fazer apresentação e explanação de idéias sem igual.

Scrum Gathering – Os desafios de escalar Scrum

maio 25, 2009

Palestra de Danilo Bardusco – Globo.com, a apresentação está disponível no SlideShare. Já havia assistido uma palestra dele e novamente foi muito competente e direto no assunto que tratava. Passando experiência de utilização e conceitos do Scrum na mesma palestra.

Antes de começar é bom saber, escalar desenvolvimento ágil é a única coisa que você deve fazer. Comece simples! A velocidade de decisão tem que ser rápida e menos pessoas decidem mais rápido.

Danilo Bardusco

Danilo Bardusco

O Scrum é auto-escalável, ele contém todos os elementos necessários para lidar com a complexidade. E para uma adoção de Scrum ser boa, ela não deve ter um único responsável, ela vai acontecendo gradualmente baseada em resultado.

De acordo com Ken Schwabber:

Scrum precisa de gerenciamento inteligente e mão na massa

Como é na Globo.com?

Na Globo.com existem dois cenários: um com equipes que trabalham independentes umas das outras e outro cenário com equipes diferentes que trabalham em um mesmo projeto.

Ao iniciar a adoção do Scrum, 7 departamentos foram transformados em 17 times Scrum. E uma lição que saiu desta adoção foi que quando se está transformando, é preciso mostrar para as pessoas porque será melhor. Ao escalar o Scrum em equipes independentes é importante lembrar de:

  • Simplicidade: é a arte de maximizar a quantidade de trabalho não feita. Se não tem certeza de que algo é necessário, não escreva o código.
  • Iterações: Ser simples significa ser incremental. O Scrum exige que você pense como uma artista, vá refinando a sua obra, vá refinando a sua idéia sobre o que deseja fazer. E você irá parar quando achar que já tem o suficiente. (Em sua apresentação ele utilizou um slide bem bacana, ilustrando esta diferença mostrando um quadro da Monalisa). Se você tem 3 dias para fazer um cadastro de clientes, faça o melhor cadastro possível em 3 dias, faça algo entregável.
  • Cliente e/ou usuário colaborando: Isto é difícil em empresas maiores. Não é para escolher nada do cliente.
  • Kaizen Mind: senso de urgência. Fazer as coisas de forma melhor.
  • Ambiente de confiança e aprendizado.Para aprender é preciso errar. As pessoas não se sentem confortáveis de apontar onde está errado. A principal coisa que gera confiançaé entregar software funcionando.
  • Entregar software funcionando a cada sprint: mesmo que seja pouco, você vai melhorando e corrigindo. Eles tinha dois problemas maiores para entregar software funcionando. Os times não eram 100% autônomos e a alta direção não se sente confortável de por algo que não está ainda pronto. Alguém pode copiar a idéia ou causar má impressão. Mas viram que é mais competitivo entregar antes do que ficar planejando.

Ao Implantar Scrum é importante saber que o Scrum não é fácil.

Escalando Scrum

No desenvolvimento da nova plataforma de gerenciamento começaram com 1 time em 12 sprints. As coisas não estavam indo bem, era preciso ser mais rápido. A direção colocou 6 times à disposição do projeto. Mesmo sabendo que 9 mães teriam um filho em um mês, eles começaram a escalar o Scrum.

  • Os times foram replicados: uma pessoa do time original foi colocada em cada um dos novos times.
  • O Product Owner original virou o Product Owner do Backlog geral.

Estes times tinham:

  • Sprint sincronizado.
  • Plannings individuais.
  • Daily meetings no mesmo horário, às 09:30.
  • Daily Scrum of Scrums às 09:50.
  • O Review é feito no auditório com todos.

Velocidade dos times

Algo que eles aprenderem neste projeto foi que é importante achar a velocidade local de um time antes de distribuir para outros times. É importante sentir se o time está desempenhando da forma que o projeto precisa antes de distribuir.

A arquitetura estava ruim, muito difícil de desenvolver. Outras coisas que aprenderam foi:

  • Integre os projetos ao menos uma vez por dia. Se a equipe demorar muito para fazer o Merge, corre o risco de ter muito retrabalho.
  • Cuidado com a automação de testes, evite gerar uma manutenção difícil. Eles gravavam muitos testes de web e depois tinham que regravar muita coisa. O mesmo cuidado que você tem com o código, deve ter com o teste.

Coordenação entre os times

É fundamental que as pessoas se falem, daily meetings e sincronismo entre os Product Owners. É preciso isolar uma user story de outra.Além disso, para facilitar a coordenação é importante não paralelizar trabalho, que nos dá os seguinte benefícios:

  • Diminui o estoque de produtos não acabados.
  • Ajuda na auto-gestão.
  • Regula o tamanho da equipe: não vai ter story para que 15 pessoas trabalhem na mesma.
  • Tira o time da zona de conforto.

Fez uma pequena observação: eles fazem reuniões semanais entre os especialistas de uma área que estão espalhados pelos times, (por exemplo designers), para que troquem experiências.

Seja preguiçoso

  • Só faça o absolutamente necessário para a meta.
  • Não reinvente a roda.
  • Simplifique.
  • Automatize depois que fizer algo, automatize tudo!

Ao fim das palestras, Danilo disse que a Globo.com é uma boa prova que se pode fazer software de qualidade sem burocracia.

Apresentação no SlideShare

Voltar para o resumo do primeiro dia