Qcon London 2009 – Mais sobre o evento, por Junior

Publicado em QCon. Tags: . 1 Comment »

Criando uma linguagem para JVM (Ioke)

Apresentação de Ola Bini

Apresentação de Ola Bini

Durante a semana do QCon London, o Ola Bini fez uma apresentação aberta na ThoughtWorks e falou sobre sua linguagem de criação, chamada Ioke. Ficamos surpresos com a quantidade de pessoas que se interessou pelo assunto, pois muitos tiveram que assistir de pé. Estive lá e conferi essa excelente palestra.

Ola Bini trabalha na ThoughtWorks e é apaixonado por linguagens de programação e inteligência artificial. Ele faz parte do principal time de desenvolvimento do JRuby e publicou o livro Practical JRuby on Rails Projects.

Ele começou explicando o que é uma JVM, hotspot, gerenciamento de memória e compilador JIT. Depois falou de JRuby, sendo a melhor implementação da lingagem Ruby para muitos propósitos.

Sobre o Ioke:

  • É um experimento. Uma linguagem de programação.
  • Dinâmica e fortemente tipada
  • Orienteção a Objetos baseado em Prototype.
  • Roda na JVM.

Propósito Geral:

Scripting, Web, Rules, DSL, Game engine.

Paradigma

Orientado a Objetos, Lógico, Funcional, Metaprogramação.

Em seguida foi explicado detalhadamente sobre a sistaxe do Ioke, como foi construído o analisador léxico, o parsing da linguagem e a diferença para o JRuby.

Integração com Java

  • Chamada de métodos java. Até mesmo métodos estáticos.
  • Converte argumentos automaticamente para os tipos corretos.
  • Cria objetos Java.
  • Mantém referência a objetos Java.
  • Converte dados de tipo primitivo em Java.
  • Trabalha com arrays em Java.
  • Implementa Java Types

Ou seja, totalmente compatível com Java.

Diferenças entre os Modelos de Objetos:

Java

  • Classes não são objetos, mas você pode chegar a ter uma representação para uma classe.
  • Métodos não são objetos, mas você pode chegar a uma representação para um método.
  • Atributos não são objetos, mas você pode chegar a uma representação para um atributo.
  • Um objeto é criado de uma classe.
  • Um objeto tem os mesmos métodos e atributos definidos na classe.
  • Métodos não podem ser mudados por Objetos
  • Atrubutos não podem ser mudados por objetos

Ruby

  • Tudo é um objeto. Classes e módulos são objetos, mas classes tem um método de alocação mágico
  • Qualquer objeto tem qualquer tipo de variáveis de instância.
  • Qualquer objeto tem qualquer número de métodos.
  • Um objeto pode ter uma classe associada. Essa classe pode ser nomeada ou uma classe singletom anônima, gerada quando o objeto faz mudanças específicas.

Ioke

  • Tudo é um objeto.
  • Qualquer objeto pode imitar zero ou mais outros objetos.
  • Um objeto tem zero ou mais células. Célula é um binding de um nome para m objeto do mesmo tipo.
  • Método é um objeto.
  • Um macro é um objeto.
  • Um pedaço de código é uma coleção de objetos.

Outros detalhes da apresentação:

Limitações da JVM, Representação de código, Representação Interna, Manipulação de erros, concorrência, manipulação de texto.

Os Slides da apresentação estão em:

http://olabini.com/presentations/CreatingALanguageForTheJVM.pdf.

O vídeo da apresentação está em:

http://skillsmatter.com/podcast/java-jee/language-on-jvm

QCon London 2009 – Projetos De Banco de Dados para ver de Perto

Geir Magnusson apresentou sobre  Cloud Data Persistence ou “We’re in a database reneaissance – pay attention” no QCon London 2009. A principal mensagem dessa apresentação foi que limitações físicas da tecnologia de hoje combinada com a complexidade computacional de bancos de dados relacionais convencionais estão nos levando a olhar para espaços novos e excitantes.

Apresentando soluções como Google’s BigTable e Amazon Dynamo , Magnusson diz que banco de dados distribuídos nos permite gerenciar um enorme volume de dados (BigTable é preparado para tabelas petabyte) mas questões de alta disponibilidade, com distribuição através de muitos sistemas, trás alguns requerimentos que geralmente necessitam de uma solução que diverge de um modelo relacional e direciona para modelos de armazenagem de documentos.

Magnusson mencionou alguns projetos interessantes para olhar de perto.

Alternativas Open Source do Google BigTable:

Alternativas Open Source para o Amazon Dynamo:

Outros projetos Open Source interessantes:

  • MongoDB, armazenagem de documento
  • CouchDB, armazenagem de documento JSon
  • MemcachedDB, banco de dados distribuído a armazenagem chave/valor, acessado via api memcached
  • Drizzle, fork do mysql direcionado a cloud
  • Hadoop, sistema de arquivo distribuído, framework M/R
  • LightCloud, banco de dados distribuído a armazenagem chave/valor, baseado no Tokyo Cabinet
  • Scalaris, escalavel, transacional, armazenagem chave/valor distribuído, em Erlang

QCon London 2009 – Um Exemplo Completo em DDD

Estive no tutorial do QCon realizado por Peter Backlund Patrik Fredriksson, que falaram sobre DDD e mostraram um exemplo com uma tecnologia atual.

Publiquei a notícia completa no site da Infoq Br nesse link.

Eles começaram com uma frase bem famosa do Eric Evans

“A complexidade crítica de muitos projetos de software está no entendimento do próprio domínio”

O maior desafio está na transferência de conhecimento entre as pessoas.

Domain-Driven Design

É a maneira de aproximar os problemas da complexidade de software através da cooperação próxima entre desenvolvedores e experts no domínio (domain). A complexidade está no domínio. Usamos modelos para manipular o domínio.

Exemplo: DDDSample

Essa aplicação de exemplo tem vários usos:

  • Um exemplo “how to” para implementação de uma típica aplicação DDD
  • Suporte para discussão e práticas de implementação
  • Laboratório para experimentos controlados.

Tecnologia

  • Frameworks e componentes baseados em Open Source
  • Bom suporte para DDD e OO.
  • Java 6
  • Spring Core/ORM/JEE/Web
  • Hibernate
  • ActiveMQ JMS
  • Apache CXF Web Services
  • Jakarta Commons
  • Maven

QCon London 2009 – O que Evans aprendeu sobre DDD desde seu Livro

Eric Evans

Eric Evans

Estive no evento QCon London 2009 e assisti a apresentação do Eric Evans sobre o que ele aprendeu após a publicação se seu famoso livro sobre DDD. Escrevi sobre o evento no site da Infoq Br

Publiquei a notícia completa no site da Infoq Br.

Os Slides da apresentação estão disponíveis aqui.

Model é um sistema de abstração que descreve aspectos selecionados de um domínio e pode ser usado para resolver problemas.

Ubiquitous Language é uma linguagem estruturada dentro do domain model e usado por todos membros do time para comunicação.

O que é essencial?

  • Colaboração criativa dos experts do domínio e experts em software.
  • Exploração e experimentação. Podem surgir idéias ruins, porém a exploração desse domínio é muito importante para um bom compreendimento
  • Modelos emergentes de elaboração e re-elaboração de uma ubiquitous language.
  • Camadas explícitas de contextos.
  • Foco no principal domínio.

Considerações Finais

  • Modelagens precisas são frágeis
  • Técnicas de Modelagem sofisticadas são gastas em uma bola de lama.
  • É necessário uma camada “anti-corrupção”.
  • Nem tudo de um grande sistema será bem modelado

Outros relatos dessa apresentação:

http://gojko.net/2009/03/12/qcon-london-2009-eric-evans-what-ive-learned-about-ddd-since-the-book/

http://www.markhneedham.com/blog/2009/03/13/qcon-london-2009-what-ive-learned-about-ddd-since-the-book-eric-evans/

Publicado em QCon. 1 Comment »

QCon London 2009 – Retrospectivas

dsc07711

Retrospectivas de times ágeis parecem ser algo bem simples de se fazer, porém na prática muitas dificuldades podem surgir. Durante sua apresentação no QCon 2009, Linda Rising falou sobre aplicar boas Retrospectivas e como não deixar que elas tenham efeitos colaterais.

Na retrospectiva acontece de o time não lembrar das coisas ruins e boas para ser discutidas e, portanto, os problemas podem continuar ocorrendo posteriormente. Outro problema que ocorre é eleger culpados, ao invés de pensar em soluções.

Algumas considerações da Linda Rising abaixo:

Em intervalos regulares, o time reflete sobre como se tornar mais efetivo, então melhora e ajusta seu comportamento em conformidade. Esses intervalos não podem ser muito longos porque os acontecimentos podem cair em esquecimento na hora da retrospectiva. O ideal é que ocorra uma mini-retrospectiva durante todos os dias. Devemos nos perguntar: “O que aconteceu nessa manhã?”. “O que eu deveria fazer para evitar que algo ruim que ocorreu hoje não ocorra mais?”. E para não cair em esquecimento, a pessoa pode escrever a idéia no cartão e colocar na parede para ser discutido na retrospectiva do sprint. Os cartões devem estar em um lugar fácil para todo o time visualizar, assim alguém pode até resolver um problema antes mesmo de ser discutido na reunião de retrospectiva. Usar cartões coloridos para identificar algo bom ou ruim também é interessante.

“Uma retrospectiva é uma oportunidade para os participantes aprender como melhorar. O foco é no aprendizado – não na busca de culpados.” Norm Kerth do livro Project Retrospectives

Reflita e encontre uma melhor maneira.

O que é uma retrospectiva?

“Temos que testar nosso conhecimento constantemente – usando práticas como retrospectivas. Isso deve ser feito depois de cada ciclo iterativo ao invés de esperar o final do projeto.” Jim Highsmith

Por que uma retrospectiva?

Retrospectivas são para aprender do passado. Queremos acreditar que aprender de experiências é automático, mas para isso é necessário habilidades profundas. Experiência fornece dados, não conhecimento.

O objetivo é planejar o futuro para se aprimorar.

“Pessoas querem aprimorar-se mas geralmente elas não sabem em que trabalhar para isso. Quando elas recebem bom feedback em pontos específicos, libera uma inclunação natural interna para melhorar” James Fallows.

“Tenho visto um um time inteiro fazendo reflexão, descobrindo, e ensinando muito. Acredito que não existe melhor maneira de melhorar a performance e qualidade do time.” Norm Kerth

Exemplos de Retrospectivas

Linda apresenta dois exemplos clássicos sobre retrospectivas.

  • Post-fire Critiques é um artigo que explica como uma retrospectiva pode ser importante em trabalhos que envolvem a vida de humanos. Bombeiros, tal como todos os seres humanos, cometem erros. Quando bombeiros cometem um erro no emprego, no entanto, pode colocar a própria vida em risco, aos seus colaboradores, e para o público que servem. No entanto, bombeiros vão continuar cometendo erros e podem repetir um erro grave.
  • The CEO & The Monk – corporate funeral.

O que retrospectiva não é?

Uma coisa muito importante é o que a retrospectiva não é.

“Não nomeie, não culpe. Mas um louvor é sempre bem vindo.”

Essa frase quer dizer que em uma retrospectiva, nunca devemos “dar nome aos bois”. Não devemos citar nomes em hipótese nenhuma. O objetivo também não é achar culpados. Por mais que todos saibam quem é o culpado, na retrospectiva devemos falar do problema mas sem falar em nomes. Linda deu um exemplo: “Devemos melhorar os processos de banco de dados. Todos sabem quem é o DBA, mas não deve ser citado nomes nunca. O objetivo é de refletir e melhorar”.

Primeira diretiva de Kerth:

“Independentemente daquilo que descobrir, temos de entender e realmente acredito que todos fizeram o melhor trabalho que poderia, dado o que ficou conhecido na época, a sua competência e habilidades, os recursos disponíveis, bem como a situação na mão”

Essa diretiva é excelente para que não sejamos direcionados a achar culpados dos erros.

Por que ter tanto tempo?

Nossa memória é pequena e seletiva. Temos a tendência em focar em eventos recentes, especialmente se eles são dolorosos. Humanos necessitam de ajuda para lembrar, transformar experiência (dados) em aprendizado (conhecimento). Facilitadores externos são requeridos

Horas apropriadas para retrospectivas

Realizar tanto no final do projeto quanto durante o projeto. Durante o projeto pode ser feita depois de um sprint ou em resposta a uma “surpresa”.

Quem deve participar?

Desenvolvedores, Marketing, QA, Gerentes.

Exercício

Linda Rising fez um exercício muito interessante sobre a linha do tempo. Pediu para as pessoas escreverem sobre acontecimentos em cartões, durante um período que representa a linha do tempo. Cartões que representam: Desafio, Surpresa e Felicidade. Cada um com sua cor respectiva. Analisando essa linha do tempo sabemos o que foi bom (What Worked Well), o que tivemos dificuldade e que surpresas ocorreram (What To Do Differently). Essa informação também ajuda a saber se tem algo mehorando, priorando ou algo que sempre ocorre dentro dos sprints.

Linha do Tempo - Sprint 1

Linha do Tempo - Sprint 1

Linha do Tempo - Sprint 2

Linha do Tempo - Sprint 2

Linha do Tempo - Sprint 3

Linha do Tempo - Sprint 3

O que acoontece antes da retrospectiva?

Requisitos de dados de eventos, dados de esforço e artefatos. Conversa com gerentes. Inquéritos com os participantes.

O que acontece durante?

Leituras, analise do passado, e preparo para o futuro. Existem alguns exercícios como: Definir Sucesso, Linha do Tempo. Durante a retrospectiva podemos determinar ações a ser tomadas nos próximos releases ou projetos e criar planos de ação para identificar o próximo “experimento”.

O que acontece depois?

Podem ser feitos Relatórios de Retrospectivas, sobre o que aconteceu bem que não deve ser esquecido. Documentar o que pode ser feito diferentemente, planos de ação, definir experimentos, aplicar patterns.

Crie Segurança

É comum que pessoas se sintam desconfortáveis em falar de problemas, principalmente se estiverem diante de seu chefe. Crie uma atmosfera segura no qual o time se sinta bem confortável para falar abertamente e honestamente.

Como o conhecimento é compartilhado?

Postando na web, encontros de time, foruns técnicos, cursos de treinamento.

Como vender retrospectivas?

Pessoas podem achar que é perca de tempo, mas o propósito de retrospectivas é o aprendizado. Evitar erros recorrentes, identificar e compartilhar práticas bem sucedidas, preparar para a próxima interação e projetos futuros.

“Todos dizem que querem aprender, mas poucos separam tempo para fazer isso”

E finalmente Linda recomenda seu livro sobre patterns:

Fearless Change: Patterns for introducing new ideas, May Lynn Manns & Linda Rising, Addison-Wesley, 2005

Publicado em eventos, QCon. Tags: , , . 4 Comments »

Relatos do QCon London 2009

dsc07574

Big Ben e London Eye

Semana passada o Junior da Bluesoft , Dairton do Agilcoop e eu estivemos em Londres para participar de um dos maiores eventos de tecnologia: QCon. O evento ocorreu em Londres, local do Big Ben e London Eye. Uma cidade muito bonita que mistura o novo e o velho. Construções muito antigas e belas ao lado de prédios moderníssimos. No evento conhecemos André e Daniel da UOL. Também tive o prazer de encontrar com os TWers Danilo Sato, Francisco Trindade e Carlos Villela.

As apresentações foram de alto nível e os assuntos interessavam em todos os setores da área de desenvolvimento de software, pois abrangeu tópicos como Agile, Java, Ruby, Arquitetura, etc. Interessou tanto para quem trabalha com desenvolvimento como pré-venda, negócios ou gerentes.

O evento foi muito bem organizado. Havia tempo para perguntas no final de cada apresentação. No intervalo de cada palestra havia um coffee-break. Os almoços organizados pelo evento também foram muito bons. Bastante networking entre pessoas das mais diversas nacionalidades. O feedback das palestras eram representadas por cartões verdes, amarelos ou vermelhos que os congressistas colocavam em uma caixa no final de cada apresentação.

Junior e Eu

Junior e Eu

Começei na segunda e terça assistindo os tutoriais. Terça a noite teve uma apresentação do Ola Bini sobre “Creating a language on the JVM”, na ThoughtWorks. Na quarta-feira, depois das palestras, ocorreu o QCon Conference Party em um pub próximo do evento. Na quinta, logo após o término das palestras, começou o Cloud Camp, uma desconferência onde algumas pessoas apresentaram rapidamente suas experiências com Cloud Computing, seguido por open spaces. Sexta teve as palestras e o encerramento.

Na segunda a tarde, durante o tutorial de DDD, estava passando por perto da conferência a Rainha da Inglaterra. Muitos sinos tocavam. Porém a palestra não foi tão prejudicada, apesar do barulho.

Rainha da Inglaterrra

Rainha da Inglaterrra

Os próximos posts nesse blog vou escrever sobre as apresentações do QCon London 2009.

Tutoriais (Segunda):

Tutoriais (Terça)

Extra (Terça)

  • Ola Bini sobre “Creating a language on the JVM”, na ThoughtWorks

Conferência (Quarta):

  • Painél de discussão sobre performance e escalabilidade, moderado por Floyd Marinescu.
  • Programming in the Small, por Mike Hill e Ivan More
  • Test Driven Development: Ten Years Later. Por Michael Feathers e Steve Freeman
  • Cloud Data Persistence. Por Geir Magnusson
  • Three years of real-world Ruby. Por Martin Fowler.
  • CI from the trenches: real-world Continuous Integration challenges. Por Julian Simpson.

Conferência (Quinta):

  • What I’ve learned about DDD since the book. Por Eric Evans
  • Coaching self-organizing teams. Por Joseph Petrine
  • The Power of Value Objects in Domain Driven Design. Por San Johnsson
  • Is Domain-Driven Design more than Entities and Repositories? Por Jimmy Nilsson

Conferência (Sexta):

  • Pimp my architeture. Por Dan North
  • Java Enterprise application standards and why the industry moved to lightweight open source. Por Rod Jonson.
  • Strategic Design. Por Eric Evans
  • DSL in Oslo. Por Amanda Laucher
  • The State of DLS Art in Ruby. Glenn Vanderburg