Blog Tecsinapse

Frequentemente escrevemos uma consulta ao banco que demora mais do que esperávamos e que precisa ser otimizada. Porém, para otimizar corretamente, precisamos entender: por que a consulta está lenta? Qual ou quais gargalos ela tem? É aí que entra o explain.

O explain é uma ferramenta disponível em diversos bancos de dados que nos permite entender qual caminho o banco vai seguir para executar uma consulta que passamos a ele. No Postgres ele tem essa cara:

testes=# explain select * from clientes where cpf = '547.838.333-38'; QUERY PLAN ----------------------------------------------------------- Seq Scan on clientes (cost=0.00..208.23 rows=1 width=54) Filter: ((cpf)::text = '547.838.333-38'::text) (2 rows)

Na saída acima, podemos ver que, para executar a consulta select * from clientes where cpf = '547.838.333-38', o Postgres passará por todos os registros da tabela, mostrando apenas os que baterem com a condição que passamos.

Numa tabela com poucos registros, passar por todos eles vai ser rápido; a consulta acima devolve instantaneamente o resultado para uma tabela com 9000 registros. Porém, numa tabela com milhões de registros, um select simples como o acima pode demorar vários segundos para executar.

Uma estratégia bastante comum para melhorar o desempenho de consultas mais frequentes é indexar valores de uma ou mais colunas usadas nessas consultas. No exemplo acima, poderíamos ter um índice na coluna cpf. Quando indexamos os valores de uma coluna, o banco mantém uma estrutura com os valores dessa coluna ordenados, de forma que fica muito mais rápido buscar valores específicos no banco. O explain nos mostra isso também:

testes=# create index idx_cliente_cpf on clientes (cpf); CREATE INDEX testes=# explain select * from clientes where cpf = '547.838.333-38'; QUERY PLAN -------------------------------------------------------------------------------------- Index Scan using idx_cliente_cpf on clientes (cost=0.29..8.30 rows=1 width=54) Index Cond: ((cpf)::text = '547.838.333-38'::text) (2 rows)

Repare como, agora, em vez de mostrar Seq Scan, ele mostra Index Scan, ou seja, ele está usando o índice que acabamos de criar. E repare, também, que os valores do cost (entre parênteses) mudaram: o primeiro número aumentou ligeiramente e o segundo caiu bastante! Esses valores são uma informação bem importante do explain: eles mostram uma estimativa do tempo que será gasto na execução dessa consulta. O primeiro valor é o tempo até o primeiro resultado e, o segundo, o tempo até completar a consulta. Ambos são valores importantes: no processamento de uma lista de valores, quanto mais rápido recebermos o primeiro valor, mais cedo podemos começar a processar. Além disso, quanto mais rápido a consulta terminar, mais cedo o banco de dados ficará livre para processar outra consulta.

Vale ressaltar que os valores que aparecem são estimativas. Isso porque, para determiná-los, o Postgres não executa a consulta que passamos para ele, apenas usa de algumas estatísticas que ele guarda sobre nossas informações. Se quisermos saber quanto tempo de verdade ele vai levar para executar uma consulta, podemos usar o explain analyze:

testes=# explain analyze select * from clientes where cpf = '547.838.333-38'; QUERY PLAN -------------------------------------------------------------------------------------------------------------------------------- Index Scan using idx_cliente_cpf on clientes (cost=0.29..8.30 rows=1 width=54) (actual time=0.068..0.069 rows=1 loops=1) Index Cond: ((cpf)::text = '547.838.333-38'::text) Total runtime: 0.091 ms (3 rows)

Veja como, agora, temos algumas informações a mais: actual runtime e total runtime. Esses são os tempos reais que o Postgres gastou na nossa consulta.

Uma consulta mais complexa

Até agora, vimos o explain de uma consulta simples. Porém, consultas que precisam ser otimizadas são, geralmente, muito mais complexas que um simples where, envolvendo joins, subconsultas e condições mais complexas. Vamos ver um caso mais complexo:

testes=# explain select count(c.*) from clientes c where exists (select 1 from pedidos p where p.id_cliente = c.id); QUERY PLAN ----------------------------------------------------------------------------- Aggregate (cost=227.43..227.44 rows=1 width=78) -> Hash Semi Join (cost=12.14..226.43 rows=400 width=78) Hash Cond: (c.id = p.id_cliente) -> Seq Scan on clientes c (cost=0.00..185.78 rows=8978 width=86) -> Hash (cost=7.06..7.06 rows=406 width=8) -> Seq Scan on pedidos p (cost=0.00..7.06 rows=406 width=8) (6 rows)

Aqui estamos fazendo uma consulta para trazer a quantidade de clientes que têm pedido registrado no sistema. Vamos entender o que o Postgres vai fazer nesse caso. Para isso, o primeiro ponto que precisamos entender é que, no explain, as linhas menos indentadas dependem das linhas mais indentadas para executar. Então, no exemplo, para o Hash Semi Join executar, ele precisou executar primeiro o Seq Scan em clientes e o Hash; este último, por sua vez, foi feito com base num Seq Scan em pedidos. Com o Hash Semi Join pronto, ele enfim conseguiu executar o Aggregate, que é o count(*) da consulta.

Será que podemos melhorar o desempenho dessa consulta criando um índice? Afinal, o Seq Scan significa que Postgres está percorrendo as duas tabelas inteiras para fazer o exists! Vamos tentar:

testes=# create index idx_cliente_pedido on pedidos (id_cliente); CREATE INDEX testes=# explain select count(c.*) from clientes c where exists (select 1 from pedidos p where p.id_cliente = c.id); QUERY PLAN ----------------------------------------------------------------------------- Aggregate (cost=227.43..227.44 rows=1 width=78) -> Hash Semi Join (cost=12.14..226.43 rows=400 width=78) Hash Cond: (c.id = p.id_cliente) -> Seq Scan on clientes c (cost=0.00..185.78 rows=8978 width=86) -> Hash (cost=7.06..7.06 rows=406 width=8) -> Seq Scan on pedidos p (cost=0.00..7.06 rows=406 width=8) (6 rows)

Mesma coisa. Ou seja, o índice, nesse caso, mais atrapalha do que ajuda! Isso porque, além de não ser usado na consulta, o índice não sai de graça para o banco: ele tem um custo (em processamento e memória) de criação e manutenção.

Mas por que o índice não foi utilizado? Porque, com base em suas estatísticas, o Postgres calculou que seria mais caro carregá-lo e usá-lo do que simplesmente montar um hash (uma tabela de espalhamento) a partir de toda a tabela de pedidos.

Mas o que é o Meteor?

Meteor é mais que um framework é uma plataforma de de desenvolvimento simples e coesa elaborada para tornar o desenvolvimento web fácil. Meteor faz parte de uma nova geração de tecnologias que trabalham para tornar a web real-time e reativa, elevando o desenvolvimento de software a novo nível, viabilizando prototipação e desenvolvimento rápidos e de quebra, produzindo aplicações cross-platform (web, Android, iOS). Veja tudo o que você "ganha" de presente ao executar um simples "meteor run".

O que mais?

Meteor é fácil de aprender

Se você der uma olhada nos 7 princípios do Meteor, um deles é "Simplicidade é igual a produtividade", tudo o que você precisa saber para implementar sua aplicação tanto no front-end quanto no back-end, seja ela web, Android ou iOS é Javascript.

Os conceitos são claros e simples, o livro mais indicado dentro da comunidade Meteor, o Discover Meteor possui menos de 300 páginas, sem deixar de fora nenhuma das ideias importantes ou boas práticas, pelo contrário, dentro desse pequeno livro você já é levado muito além do básico.

O ambiente de desenvolvimento é simples, porém robusto

Não existem mistérios em torno do ambiente, para você sair do zero ao seu "hello world" deployado em produção no meteor.com, mesmo sem nenhum conhecimento você não vai gastar mais do que algumas poucas horas.

O suporte ao MongoDb é nativo, quando você cria uma nova aplicação, você já ganha de presente o banco de dados, sem a necessidade de nenhum tipo de configuração adicional, você simplesmente usa, além disso outras opções como o Redis, MySql e Postgres também estão disponíveis.

Para programar você encontra opções ótimas de IDEs e editores com suporte total a Meteor tanto off-line (Webstorm ou Sublime) quanto on-line (Cloud 9 ou Codebox).

Apesar do Meteor executar sobre Node.js você não precisa instalar, nem mesmo conhecer nada sobre. Nada de Grunt ou Bower, nada de varíaveis de ambiente ou conhecimentos específicos.

Código cross-platform

Através do Isobuild, aplicações mobile podem ser geradas usando o mesmo código utilizado nas aplicações web, fazendo uso do PhoneGap/Cordova, uma aplicação construída com Meteor+Famo.us possui não só uma bela aparência, mas também não deixa a desejar em questões de performance quando comparadas com aplicações nativas.

Catalogo de pacotes vasto

O repositório de smart packages Meteor, o Atmosphere conta nesse momento com 4937 pacotes disponíveis, além dos 142.765 disponíveis para Node.js que também podem ser utilizados por aplicações Meteor.

Um bom exemplo de uso de um smart package é o accounts-password que prove todo o workflow necessário para que usuários possam se registrar e logar no site. Tudo o que você precisa fazer adicionar o smart package

meteor add accounts-password

E incluir os botões na sua aplicação.

{{> loginButtons}}

Pronto, agora qualquer usuário pode criar uma conta e autenticar-se no seu site. Precisa que os usuários se autentiquem com suas contas do Facebook, Twitter, Google e etc?

meteor add accounts-facebook meteor add accounts-twitter meteor add accounts-google

Pronto!

Você já tentou ou fez isso em Java por exemplo? Pois é, eu já, não foi legal.

Comunidade ativa e receptiva

Nesse exato momento, o repositório do Meteor no Github é o décimo com mais estrelas, contando com a contribuição de 199 desenvolvedores diretos. As fontes de informações são as mais diversas possíveis e sempre produzindo novos conteúdos.

Bons Livros como Discover Meteor e Meteor in Action

Forum oficial

Podcasts. Meteor Club, Meteor Interviews, The Meteor Podcast.

Reddit

Quora

Trello

Irc. Canal #meteor na rede irc.freenode.net

Twitter

Youtube

Crater.io

Codebuddies

É o futuro

A tendência é que as aplicações sejam real-time e reativas e antes do que possamos imaginar os usuários estarão exigindo que tudo seja assim, imagine ter que dar refresh no GMail toda vez que você quiser saber se você recebeu um novo e-mail. Agora pense em implementar uma aplicação que seja real-time e reativa com as tecnologias padrão de mercado. Difícil né? Elas não foram concebidas com isso em mente, Meteor por sua vez, como eu disse anteriormente, faz parte de uma nova geração de tecnologias que chegaram para solucionar esses problemas de maneira natural.

Por isso eu até arrisco dizer que Meteor chegou para ficar, garantindo trabalho,  oportunidades de negócios e diversão por pelo menos uns 10 anos.

Fontes

A TecSinapse valoriza a participação de seus colaboradores na comunidade e estaremos em peso no TDC 2013 (The Developer's Conference) em São Paulo.

Confira nossas palestras:

Trilha Java

Sexta-feira, 14:10

Migrando aplicações do mundo real para o Java SE 8 

Michael Nascimento Santos (@mr__m) e o Janario Oliveira (@janarioliver) 

Trilha Java EE

Sábado, 11:10

Como aproveitar os novos recursos do Java EE 7

Denis Tiago (@denistiago) e o Rodrigo Santos (@rodimes)

Sábado, 15:40

JSF turbinado com Twitter Bootstrap e Java EE

Filipe Névola (@FilipeNevola) - Um dos coordenadores da Trilha de Java EE

Gostaria de fazer parte deste time? Participe de nosso programa de recrutamento online http://handson.tecsinapse.com.br/.

Como usamos uma língua com acentos, nosso projetos são configurados para adotarem o encoding UTF-8. O problema é que em alguns ambientes de desenvolvimento e servidores de aplicação o encoding ISO 8859-1 (Latin-1) é o padrão. Por tratar-se de um encoding atualmente depreciado, com menor capacidade de representação (apenas um byte para representar os caracteres, enquanto UTF-8 utiliza-se de 2 bytes), temos que reconfigurar nosso ambiente e aplicação para que o UTF-8 seja utilizado. Um bom texto sobre o uso de UTF-8, com foco em seu uso para internacionalização da aplicação, pode ser encontrado aqui e uma comparação entre os dois formatos pode ser lida aqui.

Um problema bastante comum relacionado aos encodings é conhecido como Mojibake. Basicamente, dados informados pelo usuário ou já armazenados pela aplicação sob um determinado encoding passam por uma transformação usando um encoding diferente, o que leva a apresentação ou armazenamento de dados que em nada correspondem ao esperado. Por exemplo, no nosso caso informávamos o nome do produto que gostaríamos de salvar (Pão de Mel) mas havia uma conversão do encoding UTF-8 para  Latin-1 em algum ponto do tratamento da requisição, já na camada servidora, que fazia com que o texto recebido fosse “Pão de Mel“…

Além dos diversos cuidados em definir UTF-8 como o encoding padrão no ambiente de desenvolvimento (Eclipse, no nosso caso), servidor de aplicação (JBoss AS7), especificar no header das páginas HTML o encoding das páginas, etc. um cuidado adicional recomendado em boa parte das páginas relativas a erro de encoding que podem ser encontradas na internet é de criar um filtro para assegurar que tanto requests quanto responses estejam com o encoding definido como UTF-8. Essa sugestão de solução para problemas de encoding pode ser encontrada, por exemplo, aqui e aqui. Fizemos também isso, criamos um filtro para definirmos UTF-8 como encoding nas nossas requisições HTTP!

Tudo funcionava bem tanto na entrada quanto na saída dos dados até que um determinado formulário passou a necessitar do upload de um arquivo. Tratava-se de um projeto desenvolvido utilizando JSF 2 e uma das dependências do projeto já era a biblioteca PrimeFaces (PF). Nada mais natural do que utilizar o componente fileUpload do PF para fazer a carga do arquivo, certo?

A forma padrão de envio de informações de um formulário não suporta o envio de arquivos. Portanto, para trabalhar com arquivos temos que alterar o encoding do formulário para “multipart/form-data”. Para que os dados codificados desta forma sejam tratados corretamente pelo servidor, é necessário incluir um filtro indicando uma classe que fará tal tratamento. No caso do uso do PrimeFaces, devemos incluir o respectivo filtro PrimeFaces FileUpload Filter (no arquivo web.xml).

Para ilustrar, segue abaixo um formulário com três componentes: um inputText para o usuário digitar um texto, um outputText para mostrar o texto digitado e um inputFile para a carga do arquivo. 

<h:form enctype=“multipart/form-data” acceptcharset=“utf-8”>

<h1>Texto do usuário (input): <h:inputText value=”#{sandboxBean.textoUsuario}”/>   </h1>

<h1>Texto do usuário (output): <h:outputText value=”#{sandboxBean.textoUsuario}”/> </h1>

<p:fileUpload fileUploadListener=”#{sandboxBean.handleFileUpload}”  mode=”simple” />

<h:commandButton value=“Salvar” action=”#{sandboxBean.salvar}” styleClass=“btn”/>

</h:form>

</h:body>

Pois bem, o que notamos é que apesar de todos os cuidados tomados ao adotarmos UTF-8, caso o usuário digitasse textos acentuados neste formulário, eles não estavam sendo corretamente tratados. Ocorria, em algum passo, uma conversão utilizando um encoding diferente do UTF-8 especificado! 

Depois de muitos testes e validações encontramos uma explicação. O FileUpload do PrimeFaces tem uma dependência com duas bibliotecas: commons-io e commons-fileupload. E a última trabalha sempre em ISO-8859-1. Portanto, quando a classe do PrimeFaces responsável por tratar formulários multi-part fazia seu trabalho, uma conversão indevida dos textos ocorria simultaneamente. Esse problema foi discutido junto aos desenvolvedores do PrimeFaces, mas parece ainda não ter sido solucionado.

Todos sabemos que projetos em JavaEE tem seu tempo de desenvolvimento normalmente mais longo do que o tempo de outros concorrentes (PHP, Ruby, Python, ASP.NET, …). Tudo devido ao tempo do “hot deploy” da aplicação, ou seja, o tempo gasto para visualizar a página web atualizada com suas alterações realizadas.

A palavra “hot deploy” usada no titulo pode não refletir seu significado original, porque desenvolvedores têm conceitos diferentes sobre: “automatic hot swap”, “automatic redeploy webapp”, “automatic restart container”.

Diferentes modos de entender o hot deploy

hot deploy container: Reinicio automático de todo servlet container (Tomcat);

hot deploy webapp: Carregamento automático de todo o contexto e todas as classes da aplicação web;

hot deploy classes: Similar a hot-swap, onde carrega somente as classes alteradas (recompiladas) (runtime);

É obvio que o 1º é mais lento que o 2º que por sua vez é mais lento que o 3º.

Certo, e ai?! Como reduzir o tempo de hot deploy de uma aplicação Java (usando Eclipse, plugin WTP e Tomcat; Assumindo que você já tenha esse ambiente configurado)?!

Mão na massa

Criar um Novo Server WTP para aplicação web:

Configurar a aplicação no Servidor:

Abrir configuração do Server - click duplo sobre o Server adicionado:

Configurar a publicação:

Deixar marcado a opção “Auto publish when resources changes” (assim fará o Hot Deploy dos resources).

Acessar os módulos configurados no Server:

Para quando tenha uma alteração em um método não reinicie o tomcat como um todo, basta editar o módulo e desmarcar a opção “Auto reloading enabled”:

Inicie o server em modo debug e Voilà! Alterações realizadas dentro das páginas ou internas de um método já serão publicadas em sua aplicação web, reduzindo assim o tempo de deploy.

Motivo?!

Desde o Java 1.4.2, o JPDA suporta classes hot-swap em modo debug, manipulando o class loader em tempo de execução. O Eclipse faz isso através do plugin WTP sobre o nome de “Hot Code Replace - HCR”. Configurando o “auto-publish” ajuda a substituição de arquivos textos e JARs recompilados, mas não classes. Por “default”, o reinício de contexto do Tomcat irá recarregar todas as classes usando os class loaders das próprias classes e assim não tira proveito das “hot-deployed classes”.

Saiba que JPDA não é a melhor solução para fazer HCR, uma prova disso é a existência do JRebel ou do DynamicCodeEvolution. Alguns “frameworks” web (Tapestry, Stripes, Wicket, Grails, Roo) também possuem seus próprios “handlings classloader” para suportar recarga rápida. Provavelmente inspirados em alguns JARs autônomos (talvez na idéia base do JRebel). Para sua informação plugin Sysdeo do Tomcat e Jetty pode também suportar o “HCR”, no caso de não querer usar o WTP.

Limitações

JPDA HCR não se aplica em caso de:

Mudança na assinatura da classe (adição e/ou remoção de métodos e atributos);

Adição de classes sobre demanda;

Além disso, algumas chamadas de métodos (“stack frames”) não podem ser modificados, incluindo o método principal (Main) ou qualquer método que seja invocado por reflexão, ou seja, usando java.lang.reflect.Method.invoke().

(JRebel and DynamicCodeEvolution podem superar essas limitações)

Algumas configurações recomendadas para o Tomcat

Dica: Timeout do start do Tomcat pode ser entorno de 100 a 200 segundos.

Rodar o Tomcat no Eclipse (via WTP) é um pouco mais lento do que roda-lo externamente. E rodar em modo “Debug” consome muitos recursos, os quais podem resultar em erros como:

Falha na recarregamento;

OutOfMemoryError;

Para evitar isso, pode-se tentar algumas opções de configuração da JVM via parametros do Tomcat JRE. Abrir na configuração do server que configuramos as opções do “laucher”:

Acessar a aba “Arguments” e adicionar no campo “VM arguments”:

-client -Djava.awt.headless=true -Xmx1024m -Xms256m -XX:MaxPermSize=1024m -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled -XX:+UseConcMarkSweepGC

Um dos benefícios de trabalhar na Tecsinapse é o que chamamos de Ócio Criativo. Em alguns dias específicos de cada mês, cada um pode se dedicar livremente a um projeto ou atividade do seu interesse. O que pode parecer "desperdício" de tempo, na realidade se reverte em novas idéias e soluções para os problemas do dia a dia. Talvez o caso mais famoso disso seja o GMail que foi um projeto iniciado dentro do "20% time" do Google, e hoje é um dos webmails mais utilizados do mundo.

Quando iniciamos o projeto do Ócio Criativo, por volta de um ano atrás, já estava plantada na minha mente a idéia de desenvolver uma nova ferramenta. Na realidade, de certa forma, a ferramenta já existia embutida dentro do sistema que eu estava trabalhando. O que eu gostaria era poder disponibilizá-la de forma que qualquer um pudesse usá-la em qualquer um dos nossos projetos. O Ócio Criativo foi a oportunidade de colocar a idéia em execução.

Foi daí que surgiu o Glimpse. Desde o primeiro release, várias pessoas começaram a utilizá-lo nos seus projetos, e recentemente uma grande operação de migração de dados entre dois sistemas foi conduzida utilizando-o. Nosso novo desafio agora é tornar o Glimpse conhecido por outras pessoas e contar com esta colaboração para evoluir a ferramenta.

Mas enfim, o que é o Glimpse?

Muitas vezes precisamos interagir de formas não esperadas com o nosso sistema. Um caso típico disso é quando o cliente manda aquele arquivo xls de última hora e quer que os dados contidos nele sejam carregados no sistema. Ter de desenvolver um recurso no sistema para atender uma demanda que provavelmente nunca mais será necessária é um grande problema. Ter de fazer essa operação de forma manual manipulando o arquivo e escrevendo scripts SQL nem sempre é tarefa fácil também. O que o Glimpse faz é permitir que você execute um script Groovy dentro do sistema de forma dinâmica. Para quem não sabe, Groovy é uma linguagem dinâmica muito parecida com Java, ou seja, você pode fazer qualquer coisa que poderia fazer usando Java dentro do seu sistema. Atualmente o Glimpse pode ser usado com Eclipse e uma aplicação Spring, mas em breve estaremos trabalhando para termos suportes a outras IDE's e aplicações CDI.

Muitas vezes nos deparamos com a necessidade de acrescentar um acesso seguro ao nosso site ou aplicação web. Em outras palavras, queremos que a comunicação entre o cliente e o servidor seja confidencial e que os dados trafegados estejam criptografados, impedindo a sua visualização por terceiros. Também queremos que o cliente tenha certeza da autenticidade do servidor que está acessando.

Para atender esses requisitos de segurança podemos configurar o nosso servidor de aplicações (no caso o JBoss AS 7.1.1) para utilizar o protocolo HTTPS com um certificado digital que identifique o servidor e configurar nossa webapp para utilizar apenas este protocolo. Se quiser uma explicação mais detalhada continue a leitura senão clique aqui.

É importante que o certificado digital utilizado para o servidor de aplicações seja reconhecido como confiável de forma automática pela maioria dos browsers (por isso um certificado auto-assinado não serve).

Caso contrário, o usuário que acessar a sua aplicação verá uma alerta do navegador informando que o certificado em uso não é confiável. Veja um exemplo real do que acontece quando você acessa o InternetBanking da Caixa:

Para obter um certificado digital para um servidor, além dos custos, há um processo um pouco burocrático mas necessário para aumentar a segurança na sua emissão. Felizmente, muitas empresas disponibilizam um trial, com processo simplificado de emissão porém a validade do certificado é limitada, geralmente 30 ou 90 dias, que é suficiente para realizar testes ou homologação da aplicação. Utilizaremos neste exemplo um certificado trial da http://www.geotrust.com/

O primeiro passo é gerar um par de chaves (pública e privada) que serão utilizadas no pedido e na emissão do certificado. Para essa tarefa utilizaremos o keytool que vem junto com o JDK. No servidor onde o certificado será instalado execute no terminal:

keytool -genkey -keyalg RSA -keysize 2048 -keystore siteseguro.keystore

IMPORTANTE: a resposta da primeira pergunta deve ser necessariamente o domínio no qual você deseja utilizar HTTPS (ex: www.tecsinapse.com.br)

Agora precisamos gerar um CSR, Certificate Signing Request, utilizando as chaves criadas anteriormente também com o keytool:

keytool -certreq -keyalg RSA -file siteseguro.csr -keystore siteseguro.keystore

O CSR nada mais é do que um arquivo texto criptografado contendo as informações fornecidas na geração das chaves. Utilizaremos esses dados para solicitar o certificado digital para a GeoTrust.

Acesse o site www.geotrust.com e escolha a opção TRY Free SSL Trial. Preencha os dados obrigatórios e siga as instruções da GeoTrust. 

Quando perguntado sobre o CSR, informe dos dados contidos no arquivo gerado (siteseguro.csr).

Você precisará também de um email que seja do mesmo domínio do certificado (ex: [email protected]) pois um link para efetuar a validação será enviado para esse email. Também será necessário realizar uma verificação automática por telefone. O sistema de GeoTrust irá te ligar e você terá que digitar no telefone o código de validação que será apresentado na tela do pedido do certificado. 

As instruções da GeoTrust são simples e bem documentadas, basta segui-las.

Acesse o portal do usuário para baixar o certificado no formato PKSC7.

Agora basta importar o certificado baixado utilizando o comando:

keytool -import -trustcacerts -file certificado.p7b -keystore siteseguro.keystore

O próximo passo é configurar o JBoss AS 7 para utilizar HTTPS. No arquivo standalone.xml inclua o conector https no subsystem "urn:jboss:domain:web:1.1", informando o caminho e a senha para a keystore que contém o certificado:

<connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true">

     <ssl name="https" password="senha" certificate-key-file="caminho/siteseguro.keystore"/>

 </connector>

 No conector http inclua o redirecionamento para o conector https utilizando o redirect-port="443":

<connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http" redirect-port="443"/>

Obs: esta configuração considera que a porta http do JBoss é a 80 e a https é a 443.

Por último inclua no web.xml da sua aplicação as seguintes diretivas de segurança:

<security-constraint>

<web-resource-collection>

<web-resource-name>https</web-resource-name>

<url-pattern>/*</url-pattern>

</web-resource-collection>

<user-data-constraint>

<transport-guarantee>CONFIDENTIAL</transport-guarantee>

</user-data-constraint>

</security-constraint>

Com isso, qualquer acesso para a sua webapp será redirecionado automaticamente para a porta 443, forçando o uso de HTTPS, de forma transparente para o usuário.

That's all folks!

Quick and Dirty:

1 - keytool -genkey -keyalg RSA -keysize 2048 -keystore siteseguro.keystore

2 - keytool -certreq -keyalg RSA -file siteseguro.csr -keystore siteseguro.keystore

3 - Acessar www.geotrust.com, escolher SSL Free, seguir as instruções

4 - keytool -import -trustcacerts -file certificado.p7b -keystore siteseguro.keystore

5 - Incluir no standalone.xml, seção "jboss:domain:web:1.1":

<connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true">

     <ssl name="https" password="senha" certificate-key-file="caminho/siteseguro.keystore"/>

 </connector>

 6 - Alterar conector http:

<connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http" redirect-port="443"/>

 7 - Incluir no web.xml da sua aplicação:

<security-constraint>

<web-resource-collection>

<web-resource-name>https</web-resource-name>

<url-pattern>/*</url-pattern>

</web-resource-collection>

<user-data-constraint>

<transport-guarantee>CONFIDENTIAL</transport-guarantee>

</user-data-constraint>

A cobrança por produtividade pode ser algo comum na rotina diária de um desenvolvedor. Indicadores, métricas e medições tentam, de alguma forma, cobrar ou bonificar pela produtividade alcançada.

Se procurarmos na wikipedia, encontraremos que produtividade é a quantidade de saída que se obtém para cada unidade de entrada utilizada.

Porém, gosto mais de outra definição:

Produtividade = Valor Produzido / Valor Consumido

Este Valor Produzido pode ser considerado de várias formas, tais como:

Financeiro

Satisfação do Cliente

Inovação

Experiência...

Já o Valor Consumido pode ser :

Esforço

Financeiro

Tempo

Existem muitas métricas de produtividade na literatura, mas a grande maioria é baseada em quantidade, não em valor. Por exemplo:

Linhas de código

Pontos de Função

Pontos de caso de uso

Pontos de uma história de usuário

Mas, qual a produtividade de um desenvolvedor que refatora um código tosco e deixa ele com -2000 linhas de código? É certo dizer que esse desenvolvedor não foi produtivo? Eu acho que ele pode ter sido muito produtivo,  pois a refatoração pode ter trazido muitos benefícios para o projeto (velocidade de execução,  clareza no entendimento do código, etc).

Ou seja. Produtividade não pode ser um número baseado em quantidade, mas sim um número baseado no valor produzido.

Por isso, o primeiro passo é definir o significado de valor produzido para a organização (ou projeto). Com isso, a produtividade será melhor calculada.

Como definir Valor Produzido?

Existem algumas técnicas para definir valor. No site InfoQ existe um artigo que relaciona como estimar valor de negócio em metodologias ágeis. Cada uma das propostas apresentadas no artigo, no meu ponto de vista,  serve para projetos com natureza distinta.  Leia depois:

http://www.infoq.com/news/2010/01/Estimating-Business-Value

Antes de tentar calcular a produtividade do seu time, é importante primeiro aprender como calcular o valor produzido pelo time, e não quantos pontos (de função,  de caso de uso, de histórias de usuário) foram entregues.

Como aumentar a produtividade?

São inúmeros os estudos sobre fatores que afetam a produtividade. Em suma, podemos dizer que, para aumentar a produtividade, devemos:

Trabalhar Melhor: Podemos escolher  (ou combinar) 3 estratégias para aumentar a produtividade no desenvolvimento de software [3]

 Trabalhar mais rápido: utilizando ferramentas que automatizem tarefas ou aumentando a velocidade de tarefas que demandam muita mão-de-obra.

Trabalhar mais inteligente:  Melhorando os seus processos para remover ou reduzir o número de  tarefas sem valor sendo executadas.

Trabalhar menos: Fazendo o uso de componentes reutilizáveis de software. 

Segundo o estudo [3], o aumento da produtividade seria na ordem de:

Trabalhar mais rápido: 8%

Trabalhar mais inteligente: 17%

Trabalhar menos: 47%

Ter times pequenos: A produtividade diminuiu com o aumento do tamanho do time (se time cresce 10%, a produtividade diminui 5%) , e também diminuiu com o aumento do tamanho do projeto [2]

Na figura a seguir [5], podemos verificar como o aumento de produtividade não é proporcional ao aumento de membros em um time: 

Executar Ações Integradas: Para alcançar produtividade precisamos de um conjunto integrado de ações em diversas áreas. Isso inclui ferramentas, metodologias, ambiente de trabalho, educação, gerenciamento, incentivos pessoais e reuso de software [1]

Caper Jones [4] fala sobre vários fatores positivos e negativos para a produtividade no desenvolvimento de software. Dentre eles, eu gostaria de citar os 3 principais:

Fatores Positivos

Reuso de componentes de alta qualidade: +350%

Gerencia experiente: +65%

Equipe experiente: +55%

Fatores Negativos

Reuso de componentes de baixa qualidade: -300%

Gerencia inexperiente: -90%

Equipe inexperiente: -87%

Você já utilizou essas dicas de como obter produtividade e conseguiu alcançar melhores resultados? Possui uma opinião distinta (ou similar)? Por favor, compartilhe sua experiência e contribua. 

[1] Software Engineering: Barry W. Boehm's Lifetime Contributions to Software Development, Management, and Research

[2] Katrina Maxwell – 1996

[3] Barry Boehm - Managing Software Productivity and Reuse

[4] Capers Jones - Software Assessments, Benchmarks and Best Practices,

[5] Dick B. Simmons - Software Organization Productivity 

A engenharia de software antiga (dita tradicional), era baseada em muita documentação. Com o passar do tempo, foi percebido que esse excesso de documentação não ajudava (na maioria das vezes), mas sim dificultava, o desenvolvimento de um software.

Um dos grandes problemas é a imprecisão da linguagem escrita, que pode sempre gerar erros de interpretação. Por isso que, em métodos ágeis de desenvolvimento de software, considera-se melhor substituir a palavra escrita por conversas frequentes entre desenvolvedores, clientes e usuários.

Um documento de requisitos deve ser escrito somente quando ele ajuda a alcançar o verdadeiro objetivo, que é entregar software que funcione.

Em agile, existem algumas formas de documentar. Dentre elas, podemos citar as histórias de usuário.

história de usuário

Usando as palavras de Mike Cohn, "uma história de usuário descreve uma funcionalidade que tem valor tanto para o usuário final quanto para o cliente/comprador do projeto"

Uma história de usuário possui 3 aspectos (*):

Cartão: Um texto curto que ajudará no planejamento do desenvolvimento. Normalmente este descritivo é feito em um cartão (papel) ou ferramenta equivalente.

Conversas: Dialogo entre time de desenvolvimento, usuários e clientes. Para ajudar a prever e estimar os detalhes da história.

Critérios de aceitação: Detalhes que serão testados na hora de considerar se a história está pronta.

(*) Do Inglês: Card, Conversation, Confirmation

O Cartão

O cartão pode ser considerado a manifestação mais visível de uma história de usuário. Ele representa a necessidade do cliente.

Exemplo: Como usuário eu gostaria de pesquisar vagas de emprego para me candidatar a uma delas

Seria difícil iniciar a implementação e testes tendo apenas esse texto. Por isso, é comum que os detalhes sejam expressos em outras histórias. De fato, é melhor ter mais histórias menores do que ter poucas histórias grandes.

Épicos

Essas histórias grandes, que geram várias histórias menores, são conhecidas como histórias épicas ou épicos.

Exemplo:

Porém, é importante lembrarmos que a comunicação cara a cara é um dos princípios ágeis e, por isso, ao invés de escrever todos os detalhes na história de usuário, o melhor é fazer o time de desenvolvimento e o cliente discutir sobre esses detalhes. A conversação é o ponto chave, não a nota no cartão.

As histórias de usuários devem ser compreensíveis por todos os envolvidos: usuários, cliente e o time de desenvolvimento. Por isso, o ideal é que as histórias sejam escritas pelos usuários e clientes. Além disso, eles que possuem a melhor posição para descrever o comportamento que o produto deve ter, qual a linguagem a ser utilizada (baseada no negócio), e qual a priorização dessas histórias.

Porque utilizar histórias de usuários?

Devido a baixo grau de detalhamento, elas enfatizam a comunicação verbal (cara a cara) ao invés da comunicação escrita.

Estimulam o desenvolvimento iterativo.

Incentivam o adiamento de detalhes, até você ter mais entendimento e certeza do que realmente precisa. 

Escrevendo histórias de usuário

Existem algumas características importantes que devemos nos preocupar quando escrevemos histórias de usuário. Essas características são conhecidas como INVEST.

Ou seja, uma história deve ser:

Independente: Ao criar histórias de usuário, devemos evitar dependências entre elas, pois essa dependência no levam a problemas de priorização e planejamento, além de atrapalhar no processo de estimativa.

Negociável: Uma história não é um contrato, por isso ela não deve conter excesso de detalhamento. A falta deste detalhamento estimulará que a equipe esteja sempre negociando os detalhes em uma conversa com o cliente.

Valiosa: As histórias precisam ser valiosas para o cliente ou usuário. Por isso o ideal é que eles escrevam as histórias.

Estimável: Como todo planejamento é baseado em estimativas, as histórias precisam ser estimáveis. Não é necessário que o time entenda todos os detalhes da história, mas é necessário um entendimento geral da mesma para que seja possível realizar a estimativa.

Pequena: Uma história deve ser pequena o suficiente para que possa ser desenvolvida, mas grande o suficiente para que traga valor ao negócio.

Testável: As histórias precisam ser testáveis, caso contrário não será possível ao time saber se o desenvolvimento dessa história foi finalizado ou não.

Sempre que possível, testes devem ser automatizados.

Template de história de usuário

O template típico que é utilizado para criação de histórias de usuário é:

Como um <PERFIL> eu posso/gostaria/devo/quero <FUNCIONALIDADE> para <VALOR DE NEGÓCIO>

Exemplo: Como um Agente de viagens eu posso reservar lugares para facilitar o atendimento dos clientes corporativos

Critérios de Aceitação

A melhor forma de capturar as expectativas do usuário é solicitando que ele escreva testes de aceitação para uma história, que servirão como lembrança sobre como testar a história.

Exemplos: Considerar cupons inválidos, já utilizados e erros de digitação Um cupom só poderá ser utilizado 1 vez

A anotações dos testes de aceitação devem ser curtas e incompletas, pois o objetivo é transmitir informações adicionais sobre a história, de modo que o time de desenvolvimento saiba quando a história pode ser considerada concluída, mas nunca substituir a conversa entre o time de desenvolvimento e o cliente.

Durante o desenvolvimento, essas anotações são transformadas em testes efetivamente, sendo utilizados para demonstrar que a história foi completamente e corretamente implementada (Definition of Done).

Normalmente os testes de aceitação são definidos sempre que o cliente e time conversam sobre a história e querem capturar explicitamente os detalhes ou no início de uma iteração (mas antes de iniciar a codificação).

[OFF-TOPIC] (ou não) Como escrever: histórias ou estórias?

Uma dúvida que já tive e vi surgir entre colegas refere-se a qual a forma correta de escrever: Estória ou história.

O correto é história de usuário, e o motivo descrevo abaixo [1]:

Muitas gerações têm se acostumado a ver estória como uma fábula e história com algo real [...] Por volta de 1914, o folclorista, Câmara Cascudo, introduziu estória pegando a partir de story (em inglês) que se refere a uma fábula. Enquanto history é a história tratada como ciência. [...] O Dicionário da Língua Portuguesa, de Francisco Silveira Bueno, do MEC, nos diz que estória é uma imitação inútil do inglês. Mas o Dicionário Aurélio da Língua Portuguesa registrava as duas formas. [...] Depois de 1989, ano da morte do mestre Aurélio, o dicionário passou a registrar apenas história.

Resumindo: não foi a nova ortografia quem fez a diferenciação. Foi a busca pela origem.

(Obrigado Mr M pela contribuição)

E você, já utilizou histórias de usuário? Fale-me sobre sua experiência, o que deu certo (ou errado) e como utilizou em seus projetos :)

Não importa se você lidera equipes ou é liderado. Por mais que pareça obvio, é importante saber e entender as fases existentes para a formação de uma equipe, e o que fazer em cada uma delas.

O texto abaixo pode parecer óbvio, mas se você analisar mais a fundo perceberá que  já sofreu as consequências de não entender essas fases. Uma forma fácil de perceber  se você já passou por isso é lembrar se algum projeto atrasou pois novos membros foram inseridos/removidos da equipe.

Por mais que os membros sejam treinados, orientados e acompanhados, antes que a formação de uma equipe de alto desempenho aconteça, um caminho bastante acidentado será percorrido. É por isso que na maioria das equipe em formação as coisas pioram bastante antes de melhorar.

O desenvolvimento de uma equipe pode ser dividido em 5 fases:

Fase 01: Formação

A fase inicial é de exploração. Os membros da equipe sendo formada ficam animados e ansiosos pelo envolvimento em algo novo, mas isso causa insegurança e confusão. É comum a existência de muitas dúvidas: O que deve ser feito? Qual o meu papel nessa equipe? Como os outros membros trabalham?

Como ninguém sabe ao certo o que acontecerá, a produtividade é baixa.

No papel de líder de uma equipe na fase de formação, você deve fornecer as informações necessárias para que a equipe possa começar a trabalhar. Direcione e forneça propósitos claros. Incentive e permita que a equipe se conheça melhor.

Envolva a equipe na definição da forma de trabalho, escute opiniões e teste alternativas.

Fase 02: Confusão/conflito

Nessa fase as coisas tendem a piorar. A equipe fica impaciente com a falta de progresso e luta para encontrar sua forma de trabalhar em conjunto. A produtividade continua caindo.

Estimule a comunicação e atividades informais. Isso desenvolve a confiança e estabelece boas relações de trabalho.  Resolva os problemas de poder e autoridade e estabeleça um processo para tomada de decisão e os envolvidos nela. Procure permitir que a equipe se torne mais independente.

Fase 03: Normatização

A equipe começa a dar sinais de coletividade e estabelecimento de ligações entre si. Apesar da produtividade ainda ser baixa pela falta de resultados concretos, nessa fase a equipe já definiu algumas regras/normas para o trabalho em conjunto. A comunicação fica maior e a confiança se estabelece.

Faça os membros colocarem a mão na massa e trabalharem de forma cooperativa. Envolva a equipe e utilize intensamente as habilidades e conhecimento dos membros. 

Fase 04: Desempenho

Ufa! Finalmente chegamos aqui. Nessa fase o trabalho flui com facilidade, a equipe ganha confiança e começa a utilizar processos e procedimentos estruturados para se comunicar, resolver conflitos e alocar recursos.

Ao alcançar essa fase, a equipe pode regredir para as fases anteriores principalmente se ocorrer troca de membros e líderes internos.

Faça o acompanhamento e atualização dos procedimentos para que a cooperação se mantenha e aumente. Comemore as conquistas!

 Fase 05: Desintegração

Nessa fase os objetivos já foram atingidos e não há mais razão para a equipe continuar existindo.

Apesar de ser natural, é importante estabelecer um processo de transição, para garantir que o projeto seja finalizado com sucesso.

É importante conhecer e identificar essas fases, para que se possa agir de maneira apropriada em cada uma delas, facilitando a transição e atingimento da Fase Desempenho.

Você conhecia essas fases? Acha que alguma delas não existe ou conhece algum outro tipo de organização que estabeleça outras fases? Compartilhe sua opinião e experiência conosco. 

Bibliografia

O Pivotal Tracker (PT) é uma ferramenta para gerenciamento de projetos ágeis baseada em histórias de usuários.  A ferramenta chama atenção pela facilidade de uso e recursos existentes.

Disponibiliza um quadro unificado online onde a equipe pode acompanhar as histórias do sprint e o que está no product backlog:

Ao utilizá-lo, você perceberá que ele substitui muito bem um quadro físico e é muito útil quando o time trabalha de forma distribuída. Aqui na Tecsinapse, pela filosofia da empresa, o trabalho remoto é muito comum e por isso essa funcionalidade é primordial.

Além disso, o PT calcula a velocidade do time entre um sprint e outro e ajusta automaticamente o product backlog para ficar claro quantas histórias podem ser executadas nos próximos sprints.

Nas histórias podemos adicionar comentários, tarefas e anexos. Inclusive integrados com o Google Docs.

O gráfico burn down é baseado em story points. Seu uso é muito prático pois, dadas as histórias abertas e fechadas, o PT calcula e informa quanto tempo você está adiantado (ou atrasado), informando inclusive a data prevista para finalização.  Não há burn down para tarefas de uma história.

O PT fornece uma API de integração com várias funcionalidades. Já brincamos um pouco com essa API na Tecsinapse e ela funciona bem. Também possui integração com outras ferramentas. Das que utilizo, vale citar: 

- Integração com o Google docs, contas do Google (para autenticação) e Bitbucket.

A integração com Bitbucket vale uma maior atenção pois permite você rastrear os commits de uma história. Também é possível automatizar o uso do PT usando palavras chaves dentro de seus commits. Por exemplo: Se você colocar no comentário do commit algo assim: [Delivers #123456] isso marcará a história com ID 123456 no PT automaticamente como entregue.

O PT é gratuito para projetos públicos, individuais e para estudantes. Além disso, tem uma versão trial. Foi assim que comecei a utiliza-lo e não parei mais :)

Hoje fui copiar um _backup_ do _database_ de um de nossos servidores, onde o tamanho do arquivo do backup é de 1.1G. Como tenho acesso ssh resolvi usar o scp e também porque eu já conhecia o comando.

$ scp [email protected]:/path/to/file ./file [email protected]'s password: file 49% 539MB 0.0KB/s - stalled - Write failed: Broken pipe lost connection $

Durante o processo de _download_ caiu a conexão (Broken pipe) perto dos 50%. E agora começa a baixar tudo novamente?! Porque até onde eu sei o scp não retoma o _download_ de onde parou. Com uma pesquisa rápida na internet encontrei uma alternativa usando rsync.

$ rsync -h --partial --progress --rsh=ssh [email protected]:/path/to/file ./file [email protected]'s password: file 1.1G 100% 1.26MB/s 0:10:58 (xfer#1, to-check=0/1) sent 79.97K bytes received 587.40M bytes 0.89M bytes/sec total size is 1.1G speedup is 1.40 $

Assim é possível fazer _download_ de _backups_ maiores, sem medo de interromper o _download_ para continuar depois… O que significa os parâmetros do rsync:

-h, --human-readable output numbers in a human-readable format --progress show progress during transfer --partial keep partially transferred files

Também pode ser usado o parametro -P:

-P same as --partial --progress

Ficando:

A autenticação de usuários é uma tarefa bastante recorrente em aplicações, sejam elas web, mobile ou desktop. Especificamente no caso do Android, podemos utilizar as contas registradas no dispositivo para autenticar o usuário. Dessa forma, não precisaremos nos preocupar em manter informações de usuários em nosso aplicativo ao passo que trazemos comodidade para o usuário já que ele utilizará uma conta já existente. 

Para realizar a autenticação basta delegar esta operação para o AccountManager do Android. Em nossa aplicação podemos utilizar as informações da Account obtida para o que for necessário. No Android é possível utilizar vários tipos de conta como as do Twitter, Facebook e é claro do próprio Google. Veja um exemplo de autenticação utilizando uma conta do Google (se não visualizar o código abaixo, acesse aqui):

https://gist.github.com/3019932

Também é possível utilizar a Google APIs Client Library que disponibiliza alguns outros métodos utilitários para lidar com uma conta do Google através da GoogleAccountManager.

O grupo de pesquisa de métodos ágeis da USP realizou uma pesquisa para identificar a adoção dos métodos ágeis no Brasil. A pesquisa foi realizada entre 24/05 a 31/08 de 2011 e trouxe os seguintes resultados:

Características dos respondentes: A maior parte dos respondentes possui mais de um ano de experiência em métodos ágeis (28,5% entre 1 e 2 anos, 29,5% entre 3 e 5 anos). Mais da metade deles são desenvolvedores, desenvolvedores sênior, líderes de time ou gerentes.

Características das empresas dos respondentes: Empresas cuja área de TI variam entre 1 a 20 pessoas somam 54% dos respondentes. No entanto, houve participação considerável de empresas de diversos tamanhos. Mais da metade das empresas dos respondentes têm pelo menos 1 ano de experiência com métodos ágeis. 

Características da adoção: Os principais idealizadores da adoção foram desenvolvedores, líderes de projeto e gerentes de projeto, totalizando 63,7% dos respondentes. Diversas razões motivaram a adoção de métodos ágeis, destacando­‐se:

Aumento de produtividade (91%), 

Gerenciamento de mudanças de prioridade (86%) e 

Aumento da qualidade de software (83%). 

As preocupações mais frequentes na adoção foram: Falta de documentação, Falta de previsibilidade, Falta de planejamento prévio (a longo prazo).

Crescimento e estabelecimento de métodos ágeis no Brasil: 51,2% dos respondentes usam Scrum, seguido de 22,5% que adotam a combinação de Scrum e XP. 60,7% das empresas adotam métodos ágeis em mais da metade dos seus projetos. A maior parte dos respondentes (68,8%) não trabalha em projetos com distribuição geográfica. As práticas ágeis mais frequentemente adotadas pelos respondentes foram: Planejamento de Iteração, Retrospectivas, Teste de unidade, Reunião diária e Refatoração.

Principais benefícios observados: Dentre diversos benefícios que melhoraram ou melhoraram muito, os mais frequentes foram: Habilidade de Gerenciar mudanças de prioridades(76%), Aumento da Produtividade (76%) e da Qualidade (75%), Aumento da Moral do time (75%) e Simplificação do processo de desenvolvimento (75%). Em relação à velocidade dos projetos, 67,1% dos respondentes indicaram que projetos ágeis terminam mais rápido que projetos tradicionais.

Maiores desafios: 63,7% dos respondentes indicaram algumas causas de falhas de projetos ágeis, onde as mais frequentes foram: Falta de experiência com métodos ágeis (16,3%), Filosofia/Cultura da empresa vai contra os valores ágeis (12,4%) e Pressão externa para o projeto seguir ciclos tradicionais ou cascata de desenvolvimento (10,4%). 

Gostei muito de conhecer a realidade brasileira. O trabalho completo pode ser visto aqui.