@dbouwman: Some zen slides and passionate delivery at the NoSQL session… Good things! #DevSummit

O código está disponível no Github!

O primeiro dia do encontro de desenvolvedores ESRI foi um dia agitado com muito conteúdo importante e uma plenária dando uma visão importantíssima para todos que trabalham com a tecnologia. Se puder assista a plenária ou fique com meu resumo do dia:

• Com uma API com 900 tipos públicos (expostos), algumas dezenas sendo adicionadas na versão 10.1 a ESRI explica que se trata de uma complexidade necessária para as muitas funcionalidades da plataforma mas reconhece que pode simplificar as coisas, por isso está criando um modelo de objetos mais flat que encapsule parte da complexidade para as operações cotidianas. Essa API não terá os desvios causados pela opção de arquitetura COM atualmente utilizada.
• Uma nova opção de API para desenvolvimento – ArcGIS Runtime – promete muito não exigindo nem mesmo a instalação (roda de um pen-drive) e permitindo a distribuição apenas de módulos específicos (core, geocoding, etc.). Uma boa introdução pode ser vista aqui;
• O suporte 64 bits está no centro de uma revolução de performance que começa nos produtos de servidor e vai parar no desktop. Já imaginou conseguir fazer cálculo de driving distance on the fly? Foi demonstrado com uma base de dados de 4 milhões de registros;
• As APIs nativas para aplicações móveis já incluem Android, Windows Phone7 e iOS com capacidades de edição e com suporte planejado para roteirização e muito mais até Novembro desse ano;
• Anunciando um roadmap agressivo de novas funcionalidade com tempos de release muito mais curtos do que o normal, a ESRI também revisitou seu programa BETA tornando-o um programa continuado. Visite o novo site e se inscreva;
• Adeus SOCs, SOMs e outras características de arquitetura baseadas em DCOM atualmente existentes. Conheça em breve a nova arquitetura totalmente baseada em REST em um Webserver HTTP com todos os seus benefícios de escalabilidade, performance e muito mais;
• Conheça e use o novo gis.stackexchange.com.

Code for America

O destaque do dia vai para a apresentação do Code for America, uma iniciativa (e apresentação) do Tim O’Reilly da O’Reilly Media que propõe-se a resolver os problemas das cidades americanas através de iniciativas de desenvolvimento de software.

A proposta é baseada nos seguintes fatos:

• 84% das cidades norte americanas estão com problemas financeiros;
• A administração pública tem um sistema de contratação ineficiente;
• A administração pública tem silos de tecnologia que afastam a inovação;
• Os talentos não são atraídos para atuar na administração pública.

A partir de uma análise de que essa geração é a mais voltada para a administração pública (não é política, é administração!) de todos os tempos e que isso é uma tremenda oportunidade para aumentar a eficiência e performance da administração pública o objetivo da entidade suportada por grandes empresas é justamente endereçar essas questões.

A visão do Oreilly é bastante pragmática colocando na verdade o governo como uma plataforma que irá impulsionar os próprios cidadãos.

@shoshe: Why is @timoreilly interested in OpenGov? Because he believes govt ought to be a platform. Let citizens do more together #Esri #DevSummit

Essa plataforma é sobre a WEB Social e Dados Abertos que poderão mudar a cidadania.

É impressionante o que essa visão pode fazer e a profundidade que ela tem no desdobramento da administração pública como, espero, possamos ver em alguns anos.

Alguns projetos desenvolvidos dentro da organização:

• http://seaapi.com/
• http://hearnear.org/
• http://septa.mobi/
• http://phillyapi.com/
• http://adopt-a-hydrant.heroku.com/

Considerando que os fatos que impulsionam a iniciativa estão também no Brasil pergunto: será que é possível replicar a iniciativa?

A aplicação chama-se Audience Drawing (sim, para aprender direito vou internacionalizar a interface) e resolve um probleminha que sempre tenho: sortear em um auditório (ou sala) os brindes levados para serem distribuídos após minha palestra. Sempre invento critérios na hora e até já usei o Ruboto no meu X10 que teve uma boa repercussão, mas uma aplicaçãozinha vai cair bem.

Esse post trata do setup do desenvolvimento, vamos aos detalhes::

• Funcionalidades e versões planejadas e estimadas no excelente PivotalTracker (projeto compartilhado);
• Eclipse IDE (esse eu já tinha, mas fica registrado);
• Android SDK (inclusive com plugin no Eclipse);
• SonyEricsson Android SDK Add-on (só pra ter um skin legalzinho do meu celular);
• Um pacote de ícones gratuitos para Android;
• Git no meu windows (isso, não tinha. Só usava SVN);
• Criar repositório do projeto (compartilhado) no GitHub.

Para registrar, contando com o download e a escrita dessa parte (feita entre downloads), levei 30 minutos para fazer o setup (bastante simples, mas continue lendo …).

Na hora de instalar o Git optei pelo msysGit que é um pacote bem próximo ao TortoiseSVN, mas na hora de usar fiz algumas coisas na mão para aprender. O principal que aprendi foi: o instalador empacota o Cygwin e dá alguns problemas de path, principalmente para achar as chaves de criptografia.

A mensagem “Permission denied (publickey)” significa que você não criou, o git não está achando (problema de path) ou você não configurou o github para reconhecer sua chave. Essa página ajuda e minha dica é: verifique que deve haver uma pasta .ssh na raiz do diretório do usuário mas também deve haver uma pasta .ssh na raiz do diretório de instalação do GIT. Os comandos ssh estão usando na instalação, o GIT está tentando ver no home do usuário. Você pode copiar para o home do usuário ou criar um arquivo config no home do usuário conforme as últimas instruções da troubleshooting.

Vou começar lendo o Fundamentals para não fazer muita besteira. Principais lições:

• Não existe um ponto único de entrada. O Android foi feito para reaproveitar até componentes, isso significa que não há método main;
• Activities são sua camada VIEW;
• Meu sorteio com o Random.org vai ter que ser um Service, quem sabe alguém reaproveita.

Só para lembrar o código está compartilhado aqui!

O evento foi organizado pela Caelum e InfoQ Brasil (mantido pela Caelum) e contou com a participação de alguns palestrantes internacionais bem conhecidos e muitos locais também muito conhecidos. Na repercussão do evento alguém twittou “A Caelum colocou definitivamente o Brasil no panorama de desenvolvimento mundial” (ou algo assim), embora eu discorde do “colocou” porque temos outros ilustres representantes em diversas áreas, com certeza a Caelum é dos mais ilustres representantes tupiniquins nesse panorama na atualidade.

Vamos ao resumo/lições/mensagens:

• Bons profissionais são disputados: o Paulo twittou que se impressionou com a senioridade dos participantes (era de se esperar dada a senioridade das palestras) e acho que muita gente imaginou que isso ia acontecer pois vi Globo.com, Abril Digital, Boldcron/UOL, Imagem e deve ter tido mais alguém procurando bons profissionais. Apesar das ofertas (a Globo pro Rio estava pagando a mudança, 1 mês de hotel e outros mimos de recolocação não muito comuns no Brasil) acho que ninguém conseguiu muito sucesso.
  O que percebi tentando recrutar por lá é que esses bons profissionais provavelmente estão onde querem estar e a motivação para uma mudança  é muito subjetiva envolvendo muito mais qualidade de vida, questões familiares ou algum desafio técnico do que salário ou carreira. Então além do salário atualmente para recrutar é bom pensar no ambiente de trabalho, desafios técnicos/tecnologia, metodologia (fala que usa RUP lá) e principalmente desenvolvimento profissional.
• Soluções Simples para Problemas Complexos: é impressionante como por trás de atual sopa de letrinhas que temos que lidar no fim das contas as soluções são extremamente simples (arquiteturalmente falando, a implementação é que é o desafio). As palestras do Nick Kallen (Twitter) e Randy Shoup  (eBay) ilustraram isso muito bem, apesar dos números impressionantes de dados e uso dos seus sistemas a solução sempre passa por particionamento, processamento assíncrono e cache.
• Arquitetura emergente: com vários outros nomes a idéia de evolução do sistema de forma natural é realmente aplicada muito antes do batismo de arquitetura emergente. Vimos várias ocorrências (Twitter e eBay inclusive) de grandes sistemas que evoluíram passo a passo e são hoje “exemplos“. Boa lição para os adeptos do BDUF.
• Programe: se você trabalha com desenvolvimento de software, seja em que papel for (arquiteto, analista, gerente, diretor), você precisa programar. Claro que não precisa ser sua principal atividade, mas achar que pode exercer um papel de desenvolvimento sem conhecer (de verdade) os desafios do desenvolvimento (que estão na programação) é utopia.
  Conheço vários bons programadores que ao assumir outro papel (como arquiteto) acabaram se distanciando da programação e hoje são péssimos no que fazem. Atualizar-se em desenvolvimento significa necessariamente programar, codificar!
• Testes, Testes, Testes: Vi algumas palestras incríveis sobre TDD e BDD. Uma máxima do Klaus foi “Não testar hoje é anti-ético” e concordo plenamente com a idéia.
  Hoje mais do que nunca está muito fácil automatizar toda sorte de testes, não há desculpas com as várias ferramentas (gratuitas e pagas) disponíveis. (sugiro pesquisar as opções com JRuby que conheci por lá)
• Cuide da sua vida online: reencontrei diversos conhecidos virtuais de longa data, principalmente do GUJ. Participar ativamente de comunidades, contribuir e tudo mais é muito gratificante e com certeza fará diferença para sua vida profissional.

Tecnicamente há muito mais que aprendi no evento, mas o Twitter e o Slideshare estão cheios desse conteúdo.

Aguardemos os próximos eventos.

Há duas formas de mensurar, estimar e medir tarefas que vemos/aprendemos ao nos aprofundarmos em metodologias ágeis, são o famosos Story Points (Pontos ou Pontos de Estória) e Ideal Time (Tempo Ideal).

Definições

Algumas definições importantes de forma rápida e prática:

1. Desenvolvimento de software é um processo empírico e essa declaração traz toda sorte de implicações como incertezas, variáveis externas, mudanças, maturidade, conhecimento e até mesmo erros que devem ser endereçadas no planejamento (incluindo a estimativa), na execução (o processo de desenvolvimento em si), na entrega (e na forma que essa expectativa é gerada e gerida) e até mesmo no ciclo de vida do seu produto/projeto;
2. Velocidade é capacidade de entrega e só é conhecida pela entrega (histórico) que vai levar em conta o ambiente de trabalho, a maturidade da equipe, a estabilidade dos processos e do ambiente, entre outras questões. O principal ponto aqui é entender e aceitar que não existe uma conta de 8h/dia x 10 profissionais x 10 dias úteis x 0,10% do cafézinho = produção de 720 horas de trabalho bem feito;
3. Estimativa é uma E-S-T-I-M-A-T-I-V-A. Há incertezas, há erros e definitivamente não há precisão. O Gráfico de Gantt que fica bonito impresso não serve para muita coisa na parede.

Pontos

São uma medida de complexidade relativa. Não existe uma correlação com tempo cronológico e sim com tamanho e complexidade das tarefas.

Entre suas características podemos citar:

• Exige um bom “baseline” para servir de parâmetro para as definições de ponto. Ou seja, a equipe precisa conhecer bem e de forma uniforme (pessoalmente – não é preciso todos serem iguais) o que considera 1 ponto, 3 pontos (não é multiplicando o item de 1 ponto por 3), etc. Um erro muito comum nesse caso é iniciar-se com uma simples conversão de horas para pontos (ex: 4h = 1 ponto), nesse caso perde-se muito do conceito e dificilmente será possível entrar nos eixos;
• É bem difícil de explicar para o cliente ou fazer uma proposta nesse modelo se o relacionamento com o cliente não é baseado nas premissas ágeis (atualmente é comum adotar SCRUM & cia internamente mas não ter o relacionamento com o cliente nesse modelo);
• Exige alguns ciclos até que se tenha realmente uma relação com capacidade de entrega de forma uniforme e segura;
• Mudanças freqüentes na equipe tem alto impacto no auto-conhecimento e alteram significativamente a capacidade de entrega do time.

Tempo Ideal

Respondendo a pergunta “Quanto tempo, sem interrupções, você levaria para fazer ….” a estimativa resultante é feita em unidades de tempo ideal (geralmente horas).

Apesar de serem horas note que não existe o mundo ideal. Seu time será interrompido, haverá distrações, dias de pouca produtividade e inspiração entre outros fatores que farão uma tarefa de 8hi (hora-ideal) durar 14h cronológicas.

Dito isso, esse modelo ainda é mais fácil de ser adotado com alguma precisão desde o início e a comunicação em tempo ideal é mais fácil com as demais áreas relacionadas.

Considerações finais

Mais importante do que a forma de mensurar, medir ou controlar o desenvolvimento de software é a consistência e a constância dessas atividades, indepentende da abordagem utilizada.

Como algo incerto não existe uma escala certa ou errada. O bom senso nos diz que ao escolher a escala para estimar, seja em horas ideias ou pontos, a ordem de grandeza dos números deve ser diferente (não necessariamente o conceito matemático de ordem de grandeza, podemos ficar só com a idéia) já que o grau de segurança para escolher entre dois números da mesma ordem vai ser igual e não teremos realmente subsídios para escolher entre esses dois números. Por exemplo, uma tarefa pode levar 3hi ou 4hi ? Tanto faz. Agora, ela leva 2hi ou 6hi? Agora sim existe uma diferença.
Da mesma forma a partir de determinado limite qualquer número é válido. A tarefa leva 80hi ou 100hi? Novamente tanto faz, minha margem de erro é tão grande que qualquer um dos dois serve.

Claro que há vários fatores a serem endereçados como planejamento, orçamentação, precificação, dimensionamento de equipe e investimento. Isso tudo fica mais fácil se você não ignorar a natureza empírica do desenvolvimento e o processo criativo humano e lançar mãos de outros meios para respeitar essa natureza como o contrato, por exemplo.

Nesse primeiro artigo vamos entender o que é cada coisa e porque você iria querer usá-los além de instalar o básico e executar nosso Hello World.

Quem é quem

GAE (Google Application Engine)

GAE é a plataforma de infraestrutura como serviço (IaaS) do Google. Basicamente a idéia é que o Google oferece sua robusta e gigantesca infraestrutura para que você publique suas aplicações e tenha os benefícios de disponibilidade e escalabilidade que essa infraestrutura já tem sem que você tenha que se preocupar com processamento, armazenamento, links de comunicação, energia, segurança e todo o capacity planning e a redundância para esses itens.

No conceito de IaaS você paga apenas pelo que usar (em geral mensuráveis em banda, processamento e armazenamento) e com isso pode suportar um crescimento rápido assim como picos com um custo muito mais baixo do que se fosse criar a infraestrutura em um datacenter.

Há várias outras opções mas uma vantagem significativa do GAE é que você pode usar tudo isso gratuitamente para aprender e até mesmo para iniciar seu site e somente quando precisar ultrapassar os limites do gratuito (que são até bem grandes) é que você precisa se preocupar com o dinheiro. Em tempo, uma observação importante é que o Google não é muito bom em definir um modelo comercial para seus produtos corporativos e você corre o risco de descobrir daqui a pouco que o modelo comercial do GAE fica pouco competitivo em relação aos concorrentes que não tem uma versão gratuita de chamariz; isso aconteceu com o Google Maps e com o Google Applications que só agora estão entrando nos eixos comercialmente.

GWT (Google Web Toolkit)

O Google Web Toolkit é um toolkit de código-fonte aberto permitindo desenvolvedores a criar aplicativos com tecnologia Ajax em linguagem de programação Java. GWT suporta cliente-servidor, desenvolvimento e debugging em qualquer IDE Java.

Wikipedia

Para continuar falando de Google o GWT é uma poderosa ferramenta para desenvolver o frontend da sua aplicação web usando avançados recursos de Javascript (AJAX, Partitioning, Lazy Loading), comunicação (RPC & cia), depuração (debug) e teste (junit).

Escrevendo código Java bem conhecido com suas classes, eventos, gerenciadores de tela e outros recursos, o GWT compila tudo para HTML, CSS e Javascript otimizados para vários navegadores deixando você livre de boa parte da chatice de programar interface web (pelo menos para mim). Você ainda conta com um plugin para Eclipse para facilitar a vida.

Você com certeza já viu um site escrito com GWT se usa o Gmail ou Wave. Dê uma espiada nos exemplos.

Spring

Bem, Spring é o Spring. Para mim é assustador ver que o framework da moda-super-bacana que eu conheci logo no início se tornou uma empresa com tantos produtos e linhas de negócio, mas de qualquer modo aqui vamos falar apenas de uma perna do ecossistema com o Spring Enterprise.

O Spring é uma plataforma de desenvolvimento Java que abstrai muita complexidade inerente ao desenvolvimento de grandes soluções  e fornece muitos serviços de forma transparente. Ele surgiu em resposta a difícil e complexa tarefa de construir aplicações com os servidores de aplicação JEE e através da integração de diversos frameworks leves tornou mais fácil e rápido o desenvolvimento sem abrir mão da robustez & cia.

No nosso caso podemos querer usá-lo para suportar objetos de negócio, layers de serviços, manipulação de dados e camadas de aplicação no lado servidor.

Spring Roo

SpringRoo é a última moda em ferramenta de produtividade. Entenda bem, é uma ferramenta de produtividade (RAD), não uma plataforma ou framework para desenvolvimento e execução de software.

Trata-se de uma ferramenta que gera código e mantém a integridade nas alterações buscando boas práticas utilizando dezenas de tecnologias como várias soluções da família Spring, JMS, Tiles, Dojo, Hibernate, Selenium, JUnit, Solr e vários outros.

Para nosso caso queremos usá-lo porque ele assume a responsabilidade por gerar muito código extra e tedioso que uma aplicação GWT precisa (DTO, views, presenters, etc.) e as mantém em sincronismo mesmo que você altere o código Java diretamente, ele também vai nos dar suporte do Spring para codificarmos nossa aplicação no servidor e integrar a comunicação entre cliente (GWT) e Servidor (Spring). Além disso vamos deixar que ele se preocupe com as configurações para publicarmos a aplicação no GAE.

Hello World

Pré-requisitos:

1. Instale o Roo

Só isso. Depois ele (na verdade o Maven) se encarrega do resto (GWT, Spring, GAE & cia).

Agora vamos criar uma aplicação GWT para o HelloWorld (GAE virá no próximo artigo):

• Abra o console (prompt de comando) e inicie o ROO (digite ROO se você seguiu as instruções de instalação)

C:\Temp>roo
    ____  ____  ____
   / __ \/ __ \/ __ \
  / /_/ / / / / / / /
 / _, _/ /_/ / /_/ /
/_/ |_|\____/\____/    1.1.0.M1 [rev 3a0b8a3]

Welcome to Spring Roo. For assistance press TAB or type "hint" then hit ENTER.
roo>

• Crie o projeto indicando o top-level-package;

roo> project --topLevelPackage br.com.smota.helloworld
Created ...
br.com.smota.helloworld roo>

• Defina a opção de persistência (vamos usar o GAE então a combinação é essa);

br.com.smota.helloworld roo> persistence setup --provider DATANUCLEUS --database GOOGLE_APP_ENGINE

• Crie sua classe da entidade:

br.com.smota.helloworld roo> entity --class ~.Mensagem

• Adicione as propriedades da sua entidade:

~.Mensagem roo> field string --fieldName texto --notNull

• Crie os controllers:

~.Mensagem roo> controller all --package ~.web

• Configure o GWT

~.web roo> gwt setup
Created ...
Managed ...
Created ...
br.com.smota.helloworld roo>

• Saia do Console do Roo

br.com.smota.helloworld roo> exit

• Execute a aplicação

C:\Temp>mvn gwt:run

Não se preocupe, as dependências ficam em cache e o Maven vai reutilizá-las (você só precisa esperar muuuito a primeira vez). Para um HelloWorld parece muita dependência e código, aguarde para adicionarmos algumas funcionalidades nos próximos passos.

Se ficar impaciente assista esse vídeo. Até a próxima!

BlogBlogs.Com.Br

DreamHost reviews