Just Java 2008

domingo, 31 de agosto de 2008


Esta chegando o Just Java 2008, em Setembro no mês do Java a festa do Just Java será em São Paulo nos dias 10, 11 e 12 de Setembro. Será a 7a edição do principal evento da Comunidade Java Brasileira.
Serão 3 dias com várias palestras relacionadas a Java e agora com alguns temas sobre Agile, hora de aprender um pouco mais, rever os amigos e reforçar o Networking.

Eu vou representar no Just Java com duas palestras junto com meu grande amigo Renato Bellia, no dia 10 ás 15:00 hs com a palestra Java EE 6 / EJB 3.1 e o Futuro do Java Corporativo no auditório superior 2, e no dia 11 de Setembro será a vez de falar do framework Diamond Powder - Produtividade OpenSource para JavaME, que é um projeto criado pelo Bellia.

Neste projeto do Diamond Powder, tive a felicidade de participar com o desenvolvimento de um plugin para o NetBeans para facilitar a criação do Schema, que é um Hashtable que descreve o os campos do coletor, as páginas, fluxo de navegação com opção de persistência.
Você que desenvolve aplicativos embarcados vale a pena conhecer este framework!!

Site do Evento: http://www.sucesusp.org.br/justjava2008/
Grade de Palestras:
http://soujava.org.br/display/v/Grade+de+Palestras
Diamond Powder no java.net: https://diamond-powder.dev.java.net/
Blog do Diamond Powder: https://diamond-powder.dev.java.net/

Participe, é diversão garantida !

Entendendo REST (REpresentational State Transfer)

quarta-feira, 27 de agosto de 2008

Você já precisou explicitamente utilizar algum método (PUT, DELETE, POST, GET) do protocolo HTTP, muito dificil, geralmente quando o fazemos, nós fazemos isto ao desenvolver uma aplicação web para especificar o tipo de submit, enfim, agora encontraram uma solução muito útil para utilizar os tais métodos, que é através de REST (REpresentational State Transfer), que é o nome dado por Roy Fielding em sua tese de doutorado, muita gente confunde REST com Web Services SOAP, mas ambos são totalmente diferentes.

REST são serviços stateless e arquiteturas baseadas nela são construídas a partir de "pedaços de informação" únicas identificadas por URIs. Em sistemas REST, os recursos são manipulados através da troca de representações do recurso.

Ex.:
http://netfeijao.blogspot.com/colecao/marvel/spiderman/3

Neste exemplo, atráves desta URI estamos definindo como a URI mapeia nossos recursos, no exemplo fica muito fácil entender como funciona, identificamos nossa chave primária (3) no último elemento, e o nome da coleção (spiderman), podemos ainda definir um serviço que me retorne uma coleção de objetos do spiderman caso seja omitido a chave primária,

Por as URIs serem únicas ganhamos uma busca otimizada e posso ter multiplas representações oferecendo esta informação em vários tipos de formatos como XML, JSON e XHTML.

Temos um DE-PARA dos métodos HTTP com as funções CRUD que queremos desempenhar em um sistema baseado em REST, conforme tabela abaixo:

Características dos métodos HTTP em REST

Método GET.

Utilizado para retornar informação de acordo com a URI informada.
Não deve uma mudança de estado
Fica no cache.

Método POST

Utilizado para adicionar uma nova inforamação

Métodp PUT
• Utilize PUT para alterar uma informação
• Controle total na entidade utilizada quando o ID ou chave primária é conhecido

Ex.: PUT /colecao/marvel/spiderman/3-456789012


Método DELETE
Remove (logicamente) uma entidade
Ex.: DELETE /colecao/marvel/spiderman/3 (Exclui Spiderman nº 3)


Benefícios do REST.

Serviços baseados em REST são muito fáceis de entender e de se trabalhar, pois o cliente que vai utilizar o serviço REST não precisa utilizar nenhuma API especializada, ele utiliza apenas HTTP padrão =), podemos usar nosso browser para testes e experimentos.
URI é uma maneira uniforme de identificar recursos e o HTTP é o meio utilizado para manipular estes recursos.
Fácil consumir e desenvolver com linguagens de scripting..


Web Services SOAP vs Serviços REST

SOAP WS.

  • Poucas URIs, muitos métodos customizados
  • comicsPort.getComics("spiderman")
  • Utiliza HTTP para trafegar mensagens SOAP.
  • Muitos padrões (WS-*)
  • Deve seguir um contrato WSDL.
Web Services baseados em SOAP diz respeito a SOA.

ex: Serviço de venda de quadrinhos
comicService.vender("spiderman", 3, 250);

RESTful WS.
  • Muitos recursos (URIs), poucos métodos fixos.
  • HTTP é o protocolo de transporte.
Web Services baseados em REST diz respeito a um novo conceito chamado de ROA
(Resource-Oriented Architecture)

ex: Recurso de venda de quadrinhos

POST /colecao/marvel/spiderman/3-250

Para a construção de serviços baseados em REST em Java, foi disponibilizada o JAX-RS, que é uma API para Web Services RESTful, em breve vou blogar com exemplos no GlassFish

[Getting Real] Caindo na Real no Desenvolvimento de Software

sexta-feira, 15 de agosto de 2008

Este ultimo mês, finalmente li o livro da 37signals.com, chamado Getting Real, dos mesmos criadores do framework Ruby on Rails, onde eles criticam de maneira agressiva o desenvolvimento de software tradicional, e expõe os seus pontos de vista, e não dão a mínima importância de ir contra a maioria dos conceitos que aplicamos diariamente em nossos projetos.
É uma leitura no mínimo interessante, e com certeza recomendada, tem vários conceitos que ficam inviáveis de se aplicar na maioria das empresas, mas com certeza ajuda a abrir os olhos para muitas coisas, se você não quiser ler o livro, recomendo pelo menos a leitura do resumo que fiz abaixo, boa leitura !!!!
******************************************************
Caindo na Real.
Quer construir uma aplicação web de sucesso? Então é hora de Cair na Real. Caindo na Real é o menor, mais rápido e melhor caminho para construir software. Veja como:
Construir menos
Desenvolver apenas o arroz com feijão.
  • Menos funcionalidades
  • Menos opções/preferências
  • Menos pessoas e estrutura empresarial
  • Menos reuniões e abstrações
Construir software para você mesmo.
Com paixão, realmente goste do que faz, acredite no seu software, seguindo a filosofia da comunidade open source.
Viva o software que você produz, fale dele, realmente se importe com isso.
Financie você mesmo
Não conte com o dinheiro de fora. Isso pode trazer dor de cabeça, pois um projeto financiado traz consigo prazos, cobranças, expectativa, metas, inchação de saco, e por fim acaba sendo produzido um produto medíocre.
Em projeto sem dinheiro de fora você tem tempo para desenvolver e com isso mais qualidade,
O que você pode fazer em 3 meses ao invés de 6 ?
Prazo fixo, orçamento, flexibilidade no escopo.
Faça o arroz e o feijão, aquilo que será o core do sistema, o que puder ser feito dentro do prazo e do orçamento, ótimo, fora disso a qualidade do produto irá sofrer, sempre diminua o escopo, sempre haverá novas features para serem incluídas no futuro.
Tenha um inimigo
Arrume um inimigo, veja um produto no mercado que seja um concorrente e faça algo inovador no seu produto, sem querer imitir, tome um caminho oposto, e faça uma proposta diferente para abordar o seu produto.
Tendo em mente o seguinte pensamento “Não siga o líder”, conte uma história diferente para os seus clientes. Não tente convencer o seu cliente de que ele fez uma escolha errada, ao invés disso mostre as qualidades do seu software.
Menos massa
Quanto mais robusto você for, mais fácil será se adaptar as mudanças.
Menos massa diminuir o custo de mudança.
Mais massa é:
Contratos de longos termos, excesso de burocracia, decisões permanentes, reuniões sobre outras reuniões, processo moroso, inventário (físico e mental), ficar preso a fornecedores, formatos de dados proprietários, o passado mandando no futuro, roadmaps, políticas de escritórios.
Menos massa é:
Pensamento just-in-time, time com membros multi-tarefa, abraçar as regras ao invés de tentar burlá-las, menos software, menos código, times pequenos, simplicidade, formatos de dados abertos, produtos open source, uma cultura aberta que é fácil de admitir erros.
Abrace as Regras
Permita que as restrições guiem você para soluções criativas. Não reclame sobre a falta de recursos (tempo/dinheiro/equipe). Trabalhe com o que tem e veja o lado bom disto. Em um bom time, limitação traz boas idéias (inovação) e força o foco.
Tenha times pequenos
Times pequenos melhoram o entendimento do grupo, potencializa o fluxo de informação e evita guerra de egos. O ideal em um projeto é ter times de até 3 pessoas.
Seja você mesmo e sinta a dor
Seja diferente dos grandes players, trabalhando o lado pessoal sendo amigável com os clientes, dê um atendimento pessoal sempre que possível, atenda seu cliente, conheça seu cliente, por default, empresas pequenas são mais próximas do cliente, utilize isto como uma vantagem, e conheça seu cliente, que desta maneira você irá ver seu produto por um outro foco.
Sinta a dor que o seu cliente passa, quando ele reclama de alguma coisa, NÃO FAÇA OUTSOURCING DO SAC PARA UM CALL CENTER OU UM OUTRO TERCEIRO, FAÇA ISTO VOCÊ MESMO.
Passe confiança para o cliente, a nível de passar o seu número celular se possível, traga o cliente para perto de você, pois isto inspira confiança.
Mantenha o Foco.
O seu aplicativo deve ter uma identidade, um objetivo, e nunca deve perder o seu propósito, tenha sempre em mente o que ele deve fazer e nunca fuja do foco.
Eleja o cliente/mercado correto e foque somente neste nicho, se você tentar agradar a todos, nunca irá dar certo.
Ignore os detalhes no primeiro momento
Faça o seu produto o mais simples possível, pense no “floreamento” em um segundo momento, ou até mesmo deixe para lá, deixe que o usuário trabalhe como o que tem.
É um problema somente quando é um problema
Não perca seu tempo tentando arrumar bugs que não existem, não faça algo pensando em resolver um problema que não existem.
Por exemplo, porque montar uma aplicação altamente escalável em um primeiro momento, se você não sabe ainda se vai precisar, ou não sabe a quantidade de acessos sua aplicação irá ter... crie sua aplicação e depois se preocupe para resolver isto, quando sua aplicação for um sucesso. Pois se formos pensar, sempre teremos que rever a nossa aplicação, em termos de tunning, dimensionamento, etc...
Meio Produto, não Meia Boca.
Atenha-se ao que é verdadeiramente essencial. Boas idéias podem ser tiradas da gaveta. Pegue tudo que você acha que seu produto deve ser e corte pela metade. Remova funcionalidades até que você obtenha apenas o essencial. E então, repita o processo.
FAÇA ALGO QUE VOCÊ POSSA GERENCIAR.
FAÇA UM SOFTWARE PARA UM PÚBLICO GERAL E FAÇA COM QUE O USUÁRIO ACHE SUAS PRÓPRIAS SOLUÇÕES.
O Não é a resposta,
Uma vez com o produto lançado, prepare-se para uma enxurrada de requisições de usuários, do tipo, porque não colocar isso? Porque não coloca aquilo? etc...
A primeira resposta é sempre NÃO. Nós não precisamos de um milhão de funcionalidades, eu mesmo não utilizo metade das funcionalidades do NetBeans, só altere seu produto, quando começar a pipocar várias vezes a mesma requisição.
Outra coisa, você não precisa de uma lista de backlog, o fórum /lista de discussão é o melhor local, pois aquilo que realmente precisa ser feito, irá sempre aparecer.
O que você não quer?
Busque feedback dos usuários, e pergunte por funcionalidades que eles não utilizam ou coisas que eles não querem, então, tire do seu software, mantenha seu software o mais simples possível.
Coloque seu código para rodar,
Não espere muito tempo para colocar seu software no ar, coloque no ar, e vá incluindo novas funcionalidades aos poucos.
Celebre as pequenas vitórias, uma coisa importante é a motivação, diminua suas iterações, no meio de uma semana atribulada busque algo que foi feito durante a semana, uma funcionalidade, uma melhoria, retirar uma funcionalidade não utilizada e comemore... pois isto irá trazer desejo de mais pequenas vitórias.
ABOMINE REUNIÕES.
Você já parou para pensar, em quanto tempo você já perdeu da sua vida em reuniões inúteis ? Muitas né .. pois é, eu também :(,, no livro o cara detona as reuniões. Nunca faça reuniões, somente em último caso, se não tiver como evitar, faça uma reunião de no máximo 30 minutos, convide o menor número de pessoas possíveis, e procure não perder o foco. Sempre tem aquele que acaba desvirtuando para um assunto totalmente fora do foco.
Não contrate,
Mantenha um número pequeno de pessoas, somente contrate em último caso, se sair alguém, espere por um tempo, e veja se aquela pessoa esta fazendo falta, se estiver fazendo muita falta, contrate, senão, não.
Ações, Não Palavras.
Se for contratar, procure caras que fazem open-source, pois de quebra, você pode analisar a qualidade do código, cultura, nível de paixão, se a pessoa é social. Open source rules !!! Contrate caras que sabem escrever bem, tenham boa comunicação, e que sejam entusiasmadas.
Primeiro a interface,
Faça primeiro a interface, depois codifique, fica muito mais fácil quando você vê o produto.
Depois de iniciar o desenvolvimento, desenvolva de dentro para fora, começando pelo núcleo do seu código.
Trabalhe pensando nos 3 estados, no estado regular, que é quando o usuário vê a tela funcionando normalmente, estado da tela em branco, quando o usuário vê a tela ao utilizar a tela primeira vez, este estado é importante pois marca a primeira impressão. E o estado de erro, que é quando acontece algo de errado na aplicação.
Felicidade Otimizada
Utilize ferramentas que deixe seu time feliz e excitado, pois um desenvolvedor feliz é um desenvolvedor produtivo.
Se desenvolvedores fossem pagos para remover código de seus programas,.
Ao invés de escrever novo código, seu software seria muito melhor, pense nisso.
Abra as portas
Disponibilize para o mundo seu software através de RSS, APIs, Widgets etc..
Isso faz toda a diferença, se possível torne seu software extensível.
Amostra Grátis
Quando lançar seu produto, disponibilizar amostras grátis, deixe o seu cliente em potencial testar seu produto, mas deixe sempre funcionalidades na manga para o produto licenciado, deixe a funcionalidade a mostra, quando o usuário clicar na opções, avise-o esta funcionalidade é para clientes que tem uma assinatura, bla bla bla..
Não tem nada de funcional e uma especificação funcional,
Não escreva especificações funcionais, pois elas não refletem a realidade, isso é feito para fazer as pessoas felizes, ela leva para acordo ilusório, pois cada um pode interpretar de uma maneira um texto.
Especificações funcionais levam você a tomar decisões importantes quando você tem menos informação. Essas especificações não fazem você evoluir, mudar, ou revisar pois você fica preso naquele escopo.
E bata de frente com os bloqueadores, pois vai aparecer várias pessoas querendo todo tipo de documentação, o que com certeza vai atrasar todo o processo. O melhor a fazer é ter os conceitos bem formados na cabeça, iniciar um protótipo estático, isto dará uma idéia muito madura do que deve ser feito.
Mais uma vez, NÃO FAÇA DOCUMENTAÇÃO QUE NINGUÉM IRÁ LER.
Escreva estórias, não detalhes.
Lembra do user stories, então, é isso aí.
Fácil para entrar, fácil para sair,
No site, torne fácil o processo de adesão do produto e o de cancelamento, pois é mais difícil um cliente que não teve problemas ao cancelar a assinatura de voltar a assinar do que o cliente que ficou nervoso ao tentar cancelar e não conseguiu.
Evite contratos de longo termo, taxas de assinatura, etc... não tente enganar seu cliente para ganhar mais dinheiro, seja HONESTO sempre.
Luva de Pelica
Precisa dar uma má notícia como aumento de preço, faça de uma maneira que não vá agredir, ou seja, vá avisando aos poucos, enviando emails comentando de melhorias, de novas aquisições (de hardware), etc... e por isso nós próximos meses teremos um pequeno reajuste, bla bla bla.. isso dói muito menos, do que chegar na hora H e pegar o cliente desavisado, é pedir para apanhar.
Lançamento estilo Hollywood
Vá do teaser para o trailer para o lançamento.
O esquema é marketing, para o seu produto faça um lançamento no estilo Hollywood.
Teaser
Alguns meses antes, já inicie o projeto, divulgando o produto em sites relacionados, crie um logo, crie um site promocional, com algumas novidades semana a semana, para ir alimentando a curiosidade de seus futuros clientes. Crie uma lista para as pessoas receberem avisos do que está rolando, novidades.
Trailer
Nesta fase, lance um produto beta com preview de algumas funcionalidades, deixe um grupo de pessoas testarem, e colha opiniões, bugs, etc...
Lançamento
Divulgue, faça com que todos voltem a atenção para o seu software, reformule o hot site, coloque blog, tour, um overview, relate cases, Valores, formulários para inscrição, testemunhos,
Blog é o melhor marketing que existe, você não gasta nada (apenas tempo) e as vezes o efeito é melhor do que uma propaganda na mídia.
Promova seu software através da educação, ensine as pessoas a utilizarem seu software, com tutoriais, vídeo aulas, seminários, etc..
E deixe o software o mais fácil possível, utilize FAQs, e help na aplicação, tente deixar um nível próximo de zero a necessidade de um treinamento.
De um nome
Dê um nome fácil das pessoas guardarem, não precisar ser nada muito óbvio com que a sua aplicação faz.
Resposta Rápida
Responda o mais rápido possível ás dúvidas do seu cliente, o suporte rápido e eficiente deve ser a prioridade no seu negócio, e seja sempre sincero, quando acontecer algum muito errado, por exemplo, deu crash no servidor, seja sincero, e explique o que aconteceu, com certeza ele irá entender.
Mantenha o seu blog atualizado
Um blog parado, passa a impressão que o produto está descontinuado, tirando assim a confiabilidade, atualize sempre, dê uma dica, ensine uma feature, mas mantenha seu blog sempre atualizado
Saiba o que os seus concorrentes estão fazendo.
Se inscreva nos feeds dos seus concorrentes, mas não se aprofunde demais, para o seu produto não perder a personalidade
Siga a maré
Seja sempre aberto para novas possibilidades, e mudanças de direção. Seja um surfista, e não o oceano, tente adivinhar aonde a maré rebenta e se ajuste de acordo ;-).
Aplicando Caindo na Real
Execução.
Todo mundo pode ler um livro, criar um blog, ter uma idéia, todo mundo tem um primo que é web designer.
A diferença entre você e o resto é de como isso será executado. Sucesso se resume a uma grande execução.
Pessoas
Não adianta você aplicar estes conceitos, se você não tem um bom time, com pessoas que realmente gostam do que faz, que se importam com a qualidade do software, pessoas que não guardam informação. Tenha o time certo! Procure os apaixonados.

Engenharia de Software: 40 Anos de sofrimento e aprendizado

quinta-feira, 7 de agosto de 2008

Um pouco de história:
Modelo Cascata ou Waterfall:
Nas empresas que passei, pelo menos a maioria, posso dizer que trabalharam (ou trabalham) com o método cascata para o desenvolvimento de software, que tem seus prós e contras, o problema é que este modelo foi concebido nos anos 70 por W. W. Royce, e consiste na evolução de cada fase do projeto de forma sequencial (Figura 1), vemos na imagem que o primeiro quadrado inicia-se pelo "Requerimento", ou seja, é aquela fase do projeto que demora até meses para ser feita, onde o analista tem que coletar todas as informações pertinentes do projeto e definir os seus requisitos.

Pois bem, uma vez definido os requisitos e fechado o contrato ou a SLA, é montado o cronograma e iniciando a segunda fase deste modelo, a fase do "Projeto", e aí é que geralmente os problemas começam, pois muitas vezes, o cliente ao especificar um projeto não tem nem certeza do que quer, apenas uma idéia, ficando para o analista decifrar tudo o que cliente quer, e quando os requisitos chegam para os desenvolvedores, muitas vezes estes não tem nem contato com o usuário, e tem que se virar com o entendimento baseado nos documentos de especificação, o máximo é uma conversa rápida com o analista, e quando possível.
Outro problema é que estes projetos, são estimados em torno de 3 - 6 meses, e conforme o tempo vai passando, acontece coisas com o cliente e ele começa a esquecer o que foi acordado, sobrando para o pobre desenvolvedor que acaba tendo que refatorar o código para atender a necessidade do usuário, e no modelo cascata não podemos voltar uma fase, conclusão, projetos mal sucedidos, ou atrasados, ou o produto acaba não atendendo o cliente.

Modelo Espiral:


Para tentar acabar com estes problemas conhecidos do Modelo Cascata, em 1988 Barry Boehm escreveu um artigo “A Spiral Model of Software Develpement and Enhancement” , que propõe um desenvolvimento iterativo e incremental que podem chegar de 6 meses a 2 anos,


Vantagens deste modelo:
• O Modelo em espiral permite que ao longo de cada iteração se obtenham versões do sistema cada vez mais completas, recorrendo à prototipagem para reduzir os riscos.
• Este tipo de modelo permite a abordagem do refinamento seguido pelo modelo em cascata, mas que incorpora um enquadramento iterativo que reflete, de uma forma bastante realística, o processo de desenvolvimento.


Desvantagens:
• Pode ser difícil convencer grandes clientes (particularmente em situações de contrato) de que a abordagem evolutiva é controlável.
• A abordagem deste tipo de modelo exige considerável experiência na avaliação dos riscos e baseia-se nessa experiência para o sucesso. Se um grande risco não for descoberto, poderão ocorrer problemas.
• Este tipo de modelo é relativamente novo e não tem sido amplamente usado.
• É importante ter em conta que podem existir diferenças entre o protótipo e o sistema final. O protótipo pode não cumprir os requisitos de desempenho, pode ser incompleto, e pode refletir somente alguns aspectos do sistema a ser desenvolvido.
• O modelo em espiral pode levar ao desenvolvimento em paralelo de múltiplas partes do projeto, cada uma sendo abordada de modo diferenciado, por isso é necessário o uso de técnicas específicas para estimar e sincronizar cronogramas, bem como para determinar os indicadores de custo e progresso mais adequados.

RUP:

Nestes 3 últimos anos especificamente, tenho trabalhado com um híbrido de RUP, e nas minhas experiências não tenho tido o sucesso desejado, vendo a causa pude chegar a conclusão que para uma metodologia desta dar certo não dependendo só dos templates do método e das fases estabelecidas mas da cultura da empresa e das pessoas envolvidas, pelo menos nos locais onde trabalhei com esta metodologia as pessoas trabalham com RUP em uma forma cascata, e RUP pode será ágil, que é o que mostra o artigo RUP Ágil de José Papo em seu blog. Mas mesmo assim, as pessoas tendem a trabalhar com um RUP mais “pesado”, com um excesso de documentação a ser preenchida, onde para cada passo que é dado, é preciso de assinaturas dos envolvidos.
Ou seja, essa situação faz com que as pessoas envolvidas no processo (leia-se cliente, fornecedor, terceiro) acabam entrando em conflito, pois imagine a seguinte situação, eu tenho um determinado cliente que pede uma determinada funcionalidade no sistema DELE, após eu(analista) colher o requisito, eu tenho o trabalho de documentar isso em um documento definindo as fronteiras do sistema, identificando principais envolvidos/interessados e priorizando suas necessidades, e os requisitos funcionais e não funcionais, pois bem, depois de todo este trabalho, antes de fazer qualquer coisa eu tenho que pegar um documento assinado ou email, provando que foi uma solicitação real e será implementada de acordo com a especificação.
É normal que o cliente terá receio de assinar qualquer documento, pois na cabeça dele, ele pensa que se acontecer alguma coisa errada no processo, a culpa irá recair sobre ele por causa deste documento assinado. Isso vai gerando um desconforto muito grande entre os envolvidos, e o atraso é evidente pois para cada passo é preciso da aprovação do cliente, cada fase do projeto é auditada. Então me diga, Cadê a agilidade?
Lembro que estas foram as minhas experiências com RUP.
Será que não tem algo errado nisto ? Por quê muitas empresas utilizam processos de desenvolvimento de 40 anos atrás, sendo que todo ano é publicado o relatório do Caos pela Standish Group International, onde até o ano passado, 1 entre 3 projetos estouram o orçamento,

Foram por causa dessas perguntas que comecei a me interessar por meios alternativos de gerenciamento de projeto, foi quando conheci as metodologias ágeis. E descobri algo que o que realmente faltava nestes processos / modelos / metodologias, e é algo que é o ponto chave em metodologias como SCRUM, é que esta metodologia é centrada em PESSOAS, GENTE, SER HUMANO, agora que as outras não priorizam. Desenvolvimento LEAN. Veja alguns dos principios:

“Indivíduos e interações são mais importantes que processos e ferramentas.”

“Software funcional é mais importantes que excesso de documentação.”

Para uma idéia melhor sobre o que que é manifesto ágil, veja meu outro post Agile Manifesto – Metodologias Ágeis.

E essa descoberta mudou radicalmente o meu processo de pensar, é a solução para todos o problemas? NÃO.

Mas com certeza é um passo muito importante para quebrar o paradigma de desenvolvimento de software tradicional.

Aos poucos vou falar sobre estes processos ágeis, recomendo que você leia as seguintes matéria.


Blog:

Agile Manifesto – Metodologias Ágeis
TDD – Test Driven Development
SCRUM – Uma abordagem prática

Livros:
Agile Software Development with SCRUM
Extreme-Programming-Explained
User Stories Applied
Lean-Software-Development

The Developers Conference 2008

sexta-feira, 1 de agosto de 2008

Nos dias 26 e 27 de Julho foi realizado o The Developers Conference 2008, um evento organizado pela Globalcode, com patrocinio da JBoss, UOL e a Locaweb. E posso dizer com certeza que este foi o melhor evento de Java no ano até o momento aqui no Brasil.

Tivemos uma série de palestras altamente técnicas distribuídas em 2 tracks, uma para Java e outra voltada mais para metologias ágeis.

Caption: Sr. Rubens, Renato Bellia, Melissa e Wagner

O evento agradou ambos os mundos tanto os amantes de metologias ágeis, quanto os amantes do Java,



Pude conferir as seguintes palestras:
Dia 25/07
  • KeyNote com Burr Suttler sobre a plataforma SOA da JBoss, passando um ótimo overview com algumas dicas práticas utilizando jBPM, Seam e Drools.
  • Arquiteturas SOA com ferramentas Open-Source com Edgar Silva, também outra ótima palestra com direito a uma demo com Rest / jBPM e Seam.
  • Depois fui ver a palestra do meu "guru" e amigo Renato Bellia, criador do framework Diamond Powder sobre arquiteturas de Persistência.
  • Uma introdução a Restful WebServices com uma interessante palestra com Rafael Nunes.
  • JSF 2.0 - Com o "pai da criança" Ed Burns, dando uma visão geral do que vem por aí..
  • Java Module System e OSGi em uma palestra com Vinicius Senger, que roubou a cena apresentado OSGi com uma animação usando Sketch up da Google.
  • Java EE 6: A Community Update com Reza Rahman, membro do expert group da JSR que define o EJB 3.1, dando uma geral nas novidades da plataforma Java EE 6.


Dia 26/07 Esse dia para mim foi muito produtivo também pude aproveitar muito bem as palestras, acompanhei o Key Note do Ed Burns, sobre o seu recente livro Secrets of the Rock Star Programmers nesta palestra Ed mostrou várias entrevistas com programadores famosos, um momento bem descontraído.
Depois assisti uma palestra muito boa do Manuel Pimentel sobre Modelagem Ágil, dando um overview sobre as metodologias ágeis. A seguir, acompanhei a palestra de Paulo Viragine da JBoss sobre o framework Seam, sem dúvida muito bem "mandada", dando várias dicas de produtividade com o JBoss Developer Studio.
Após a palestra sobre o JBoss Seam, assisti a palestra de Andre Piza da UOL, sobre SCRUM e o case de como eles trabalham e implementaram na UOL, para mim foi muito interessante também, pois pude ver de perto o que o pessoal esta fazendo e o que está dando certo na UOL, recentemente tirei a certificação de Scrum Master e estou tendo a oportunidade de aplicar esta metodologia na empresa que estou prestando serviços atualmente.
Depois acompanhei a palestra Dr. Spock e do Ricardo Jun sobre o leque de opções do Spring, para mim foi interessante, pois para ser sincero não tive a oportunidade de desenvolver com esta tecnologia ainda.


E por fim, acompanhei o que para mim foi um dos momentos mais interessantes do evento, que foi o Painel Gestão, metodologias e processos de software mediado muito bem pelo Jorge Diz da Globalcode, com a presença de vários caras feras no desenvolvimento ágil como Vinicius Teles da ImproveIT, Manoel Pimentel (Visão Agil), André Piza (UOL), Juan Bernabó (TeamWare), Enio Stein (Paggo), José Papo (BRQ) e o pobre Marcos Dorça da Borland levantando a bandeira do CMMI, tive o privilégio de ser o primeiro a fazer uma pergunta (que ficou sem resposta) ao grupo quando foi aberto para o público, e perguntei para o Marcos Dorça como o cara faz para aplicar um modelo de maturidade baseado em CMMI utilizando uma metodologia ágil como SCRUM sem ferir os princípios de agile (entendeu porque ficou sem resposta :D). O que acabou levantando uma polêmica e o pobre rapaz acabou sendo sufocado pelos colegas... mas falando sério, foi um painel muito legal onde todos interagiram e puderam dar os seus pontos de vista !



No geral o evento foi muito bom por outros fatores, pude encontrar amigos como Renato Bellia, Mauricio Leal, Leandro Vil, Vinicius e Yara Senger, Kleber, Melissa, Waldir, Ana, Luca, Edgar Silva, Ed Burns, Jorge Diz, Juan Bernabó, Alessandro Lazarotti, Jefferson Prestes, Fabiano Silva entre outros e também pude conhecer caras incríveis como Reza Rahman, Bruno Ghisi e o Ricardo do GUJSC, Manuel Pimentel e Felipe Rodrigues, este último acabei tendo um contato maior agora com a InfoQ Brasil por intermédio do Manuel Pimentel, ou seja, o evento foi um ótimo local para fazer um network, muito importante na nossa área.



















Só achei uma pena uma coisa, pois não pude assistir as outras palestras, como a do Mister M sobre Java SE 7, o comparativo de frameworks, extreme programming e muitas outras.




No mais, parabéns para a Globalcode, e um parabéns especial para o Leandro Vil e para a Yara Senger que organizaram o evento na "unha", espero participar mais vezes desta festa !!!

Sucesso !!!

Fotos do evento