Festa para Crianças Carentes

Garantir a alegria de dezenas de crianças carentes no mês especialmente dedicado à garotada. Esse é o objetivo da campanha “Solidariedade não se economiza”, que promete agitar o mês de outubro dos moradores da área de abrangência do Centro de Saúde Jardim Filadélfia, na região noroeste da capital mineira.

A campanha arrecada brinquedos (e também roupas, livros e alimentos não perecíveis) para celebrar o Dia das Crianças com moradores dos bairros Jardim Filadélfia, Filadélfia, Álvaro Camargo, Frei Eustáquio, Glória e Novo Glória. A festa será realizada no sábado, dia 29 de outubro, a partir das 9h, no próprio Centro de Saúde do Bairro Jardim Filadélfia, localizado na Rua Régida, 319.

A campanha “Solidariedade não se economiza” é uma iniciativa do WebDescontos, que doa brinquedos novos e está em busca de parcerias para alegrar a manhã do dia 29 dessa criançada! Até agora, já está confirmada a presença de uma máquina de algodão doce, além de oficina de balões, desenho de rostos, fantasias, cama elástica e gincanas.

Os interessados em contribuir para a campanha devem entrar em contato através do email contato@webdescontos.com.br ou pelo telefone (31) 3037-4029. O posto de arrecadação fica localizado na Av. Afonso Pena, 4000 (3º andar, sala 7) – bairro Cruzeiro.

Evento JBossInBossa2010

Pessoal,

Venho convidá-los para um evento da Comunidade JBoss Brasil. O evento irá acontecer em SP e conta com a participação de vários líderes de projetos Open Source. Segue mais detalhes do evento:

Evento

Horário: 7 maio 2010 às 14:00 a 8 maio 2010 às 20:00
Local: Anhembi Morumbi – Casa do Ator, Campos Vila Olimpia
Organizado por: Land do Brasil

Descrição do evento:
internacionais que são líderes de projetos opensource, bem como palestras da comunidade brasileira que desenvolve e fomenta tecnologias relaciodas além do time brasileiro JBoss que atua em diversos projetos de missão crítica que usam tecnologias de ponta em projetos em todos os lugares do Brasil.
Presenças Internacionais da Red Hat/JBoss, eXo Platform e PlugTree/Drools

Pete Muir é o primeiro palestrante internacional a confirmar presença no JBoss In Bossa 2010, você não vai perder a oportunidade de saber tudo da JSR299 – CDI e sobre as novidades do JBoss Seam.

Pete Muir é o Líder do projeto Seam e do Weld(Implementação de referência da JSR 299 – Contexts and Dependency Injection for Java EE), além de desenvolvedor líder do Aquillian, um conjunto de utilitários para testes de Servidores de Aplicação. Pete é um funcionário da Red Hat Inc, como Core Developer trabalhando em vários projetos de código aberto JBoss.
Pete tem palestrado em várias conferências como Devoxx, Jax, JBossWorld, JSFDays e JavaBlend, além de várias palestras em JUGs sobre Seam. Ele escreve sobre Seam, Weld e Java em seu blog: http://in.relation.to/Bloggers/Pete

Benjamin Mestrallet é o CEO da eXo Platform, uma empresa francesa que ele fundou logo após a universidade para atender seu primeiro cliente: Departamento de Defesa Americano. Com a recente expansão da Exo para os EUA, Benjamin supervisiona de São Francisco-EUA o crescimento da companhia , marketing e estratégia de vendas. Ele criou o projeto eXo enquanto ainda estudante em Dezembro de 2002, entregando o primeito Java Portlet Container da indústria. Em reconhecimento a sua liderança, Benjamin recebeu o prêmio de “Estraordinário Jovem Líder de Tecnologia de 2008″, o IVY Award na França. Ele possui Mestrado em Ciência de Grenciamento pela Universidade de Paris IX Dauphine. Site da eXo Platform: http://www.exoplatform.com

Mauricio Salatino é CTO na PlugTree (http://www.plugtree.com), uma empresa especializada no fornecimento de soluções usando a plataforma Drools com escritórios em Miami, EUA e Buenos Aires, Argentina. Maurício é committer no projeto Drools, e vem desenvolvendo inúmeros projetos com os conceitos de Motor de Regras, CEP(Complex Event Process) BPM e portais com Alfresco, autor do livro: jBPM Developer Guide pela PacktBuk, é o fundador do grupo de usuários JBoss da Argentina(http://www.jbug.ar), é formado em Engenharia de Sistemas pela Universidade de Mendonza – Argentina, escreve regularmente em seu blog: http://salaboy.wordpress.com

Confira a Agenda completa aqui: http://www.jbossinbossa.com.br/2010/agenda.html

Ver mais detalhes e RSVP em JBoss Brasil:

http://jbossbrasil.ning.com/events/event/show?id=2234825%3AEvent%3A19199&xgi=48yfZiTpQVlyHY&xg_source=msg_invite_event

É um evento bem interessante e com certeza contribuirá bastante para arquitetos e desenvolvedores.

[]s,

Samuel

Performance de aplicações WEB

Olá pessoal,

Tenho encontrado constantemente sites com problemas sérios de performance. Algumas das vezes temos problemas estruturais sérios, mas algumas vezes os problemas podem ser simples de resolver e pequenos ajustes representam grande melhoria na experiência do usuário.

Quando dizemos performance de aplicações, logo os desenvolvedores pensam em grandes mudanças estruturas como cluster, melhorias na JVM, máquinas novas, cache de banco de dados e outras. Isto também são melhoras importantes, mas quando se trata de aplicações web, a percepção da performance pelo usuário, pode ser melhorada por otimizações mais simples como mudanças no front-end da aplicação.

Podemos encontrar as melhores práticas sobre performance de aplicações web em http://developer.yahoo.com/performance/rules.html. Entre as dicas descritas no documento acima temos:

* Fazer menos requisições HTTP

* Adicionar um cabeçalho “Expires” na resposta HTTP

* Utilizar Gzip para compactar os componentes da página

* Colocar os Stylesheets no topo da página

* Colocar os Scripts no fim da página

* Evitar CSS Expressions

* Colocar os códigos JavaScript e CSS em arquivos externos

* Reduzir DNS Lookups

* Compactar os códigos JavaScript

* Remover Scripts duplicados

* Evitar Redirects

* Configurar as ETags

* Make Ajax Cacheable

Uma ferramenta que auxilia bastante é um addon do mozilla que chama YSlow que é um addon desenvolvido pela Yahoo. Este addon analisa com base nas melhores práticas documentadas no artigo acima quais regras estão sendo usadas.

Uma dica que me ajudou bastante em algumas aplicações que trabalhei foi a de habilitar a compressão de páginas. Existem páginas que são grandes, o que faz com que o acesso seja lento em conexões de rede ruins.

Esta compressão de página basicamente troca o requisito banda por CPU. Os passos realizados para a compressão são os seguintes:

1 – O browser do cliente faz uma requisição e envia para o servidor no cabeçalho que o browser aceita arquivos comprimidos.

2 – O servidor verifica que o browser que fez a requisição aceita arquivos comprimidos.

3 – O servidor comprime a página e envia para o cliente.

4 – O cliente descompacta a página recebida e exibe para o usuário.

Podemos utilizar para a compressão de página o apache com o módulo mod_deflate. Para explicações mais detalhadas sobre como funciona o mod_deflate verifiquem a documentação em http://httpd.apache.org/docs/2.0/mod/mod_deflate.html.

É isto ai pessoal. Espero que vocês sigam as orientações, para o bem de suas aplicações e de seus usuários.

Cache de páginas com o framework EhCache

Olá pessoal,

Há bastante tempo não escrevo nada. Resolvi falar agora sobre melhorias de performance que ajudam bastante a aplicação. Em sites, constantemente temos páginas que acessam várias consultas pesadas além de regras de negócio. Estas páginas quando muito acessadas causam freqüentemente problemas de desempenho na aplicação e páginas lentas.

Um dado importante para se tomar a decisão de utilizar ou não cache em páginas é a relação entre corretude e performance. Imagine o seguinte caso: Você tem uma página que possui as últimas notícias da sua empresa. Se uma nova notícia nova acaba de sair, qual o impacto da notícia demorar um pouco a mais para entrar no ar? O ganho de performance vale a pena o atraso na notícia. Se sim é interessante utilizar neste caso o cache para esta página.

Quando temos cenários parecidos com este podemos verificar se é possível realizar cache de páginas. O Ehcache que é um framework java possui além do cache de objetos e cache para acesso a dados com JPA, possui também cache de páginas. Este cache às vezes é mais interessante, porque uma mesma página pode possuir várias consultas e regras de negócio, o que faz com que o cache de página geralmente gere mais ganho de performance do que o cache de acesso a dados.

Para definir o cache de páginas é necessário primeiramente baixar os jars do ehcache disponíveis em http://ehcache.org. Entre os jars necessários é necessário baixar o módulo ehcache-web, que possui a Servlet responsável por gerenciar e guardar o cache das páginas.

Depois disto, no classPath (pode ser na pasta src por exemplo) deve ser adicionado o aquivo ehcache.xml com um conteúdo parecido com o abaixo:

<?xml version="1.0" encoding="UTF-8"?>
<ehcache>
    <diskStore path="java.io.tmpdir" />
    <cache name="SimplePageCachingFilter" maxElementsInMemory="10"
        eternal="false" timeToIdleSeconds="600" 
        timeToLiveSeconds="600" overflowToDisk="true" />

    <defaultCache maxElementsInMemory="10" eternal="false"
        overflowToDisk="false" timeToIdleSeconds="120" 
        timeToLiveSeconds="120" diskPersistent="false" 
        diskExpiryThreadIntervalSeconds="120" />
</ehcache>

Para o arquivo acima é necessário verificar o tempo de expiração do cache que é definido pela propriedade timeToLiveSeconds que representa o número de segundos do cache da página apresentada.

Depois, no arquivo web.xml devemos adicionar o filtro de cache para as páginas necessárias, assim como mostrado abaixo:

<!-- Filtros para cache de páginas adicionado para páginas -->
<filter>
    <filter-name>SimplePageCachingFilter</filter-name>
    <filter-class>
        net.sf.ehcache.constructs.web.filter.SimplePageCachingFilter
    </filter-class>
</filter>
<filter-mapping>
    <filter-name>SimplePageCachingFilter</filter-name>
    <url-pattern>/index.jsf</url-pattern>
</filter-mapping>
<filter-mapping>
    <filter-name>SimplePageCachingFilter</filter-name>
    <url-pattern>/noticias.jsf</url-pattern>
</filter-mapping>
<filter-mapping>
    <filter-name>SimplePageCachingFilter</filter-name>
    <url-pattern>/rss.jsf</url-pattern>
</filter-mapping>

A melhoria de performance é bastante significante. Além do cache de páginas comum é possivel também compactar as páginas, adicionar cabeçalhos, entre outros. Para mais informações visitem http://ehcache.org/documentation/web_caching.html.

É isto aí pessoal. Qualquer problema avisem...

Resultado da enquete sobre certificações Sun

Olá pessoal,

Chegamos ao resultado de mais uma enquete. Desta vez sobre certificações Sun. Segue abaixo o resultado:

Pelas respostas dos visitantes do site vimos que a grande maioria (57%) ja possuem a certificação de Programador (SCJP). Logo atrás em segundo lugar, com 38% das respostas estão os visitantes que responderam que não possuem nenhuma certificação.

Em terceiro lugar com 32% estão os certificados em Desenvolvimento Web (SCWCD). Muito próximo, logo abaixo estão os visitanes com certificação Associate (SCJA) e em Componentes de Negócios (SJBCD) com respectivamente 18% e 16% das respostas.

12% dos visitantes que responderam a enquete possuem a certificação de arquiteto (SCEA) e 7% a de Web Services (SCDJWS). Por último ficaram as certificações de desenvolvedor (SCJD) e de desenvolvedor para aplicações móveis (SCMAD) empatados com aproximadamente 6% das respostas.

Nesta última votação tivemos uma participação ainda mais ativa dos visitantes. Em breve teremos novas enquetes e continuem votando.

É isto aí pessoal.

Apache Native Library no Tomcat ou Jboss

Olá pessoal,

Trabalhando com melhoria de performance de aplicações a algum tempo verificamos algumas mudanças que podem ser aplicadas no servidor de aplicação e que surtem efeito na aplicação como um todo. Entre estas melhorias uma que é uma opção para aplicações que utilizam servidores como o Tomcat e o JBoss é a utilização do Apache Tomcat Native Library (APR).

O Apache Tomcat Native Library é um JNI (Java Native Interface) que provê grande parte das funcionalidades do Tomcat em código nativo ao invés de utilizar Bytecode Java. Isto na prática significa maior velocidade da aplicação, uma melhor escalabilidade e melhor integração com os serviços nativos da máquina. Por default o Tomcat não vem com o APR já compilado e aplicado a distribuição, pois isto tornaria o servidor dependente de plataforma, mas sua utilização é bastante recomendável em ambientes de produção.

Entre as vantagens de sua utilização temos acesso a funcionalidades avançadas de IO (SendFile, Epoll e OpenSSL), funcionalidades do sistema operacional (Geração aleatória de números, status do sistema, etc.) e acesso a processos nativos (Memória compartilhada, NT pipes e Sockets).

Quando o APR não está instalado vemos o seguinte log no servidor de aplicação:
The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path

Para instalá-lo utilize os passos descritos em http://tomcat.apache.org/tomcat-6.0-doc/apr.html ou em http://www.liferay.com/web/guest/community/wiki/-/wiki/Main/Tomcat+Native+Library.

Assim que ele estiver instalado vemos o seguinte trecho no log do Tomcat:
INFO: Loaded APR based Apache Tomcat Native library 1.1.16.

Realizar os testes para verificar o quanto melhorou no desempenho da aplicação é um processo um pouco complicado, pois algumas operações podem ser mais beneficiada que outras. Em algumas referências vimos um ganho de até 10% na performance da aplicação em geral, mas realmente é um teste difícil de ser realizado.

Em um teste bem curto que fiz verificamos as seguintes medições apenas do tempo de startup do servidor sem e com a API nativa tive os seguintes resultados:

Tempos sem lib native:
2125 ms
2155 ms
2113 ms

Tempos com lib native:
1913 ms
1984 ms
1985 ms

Vimos então um ganho que se aproxima de 10% apenas para o startup do servidor.

É isto aí pessoal. Espero que isto ajude quem necessita otimizar a performance das aplicações.

Quaisquer problemas avisem...

Implementando página de erro com JSF

Algumas pessoas estão tendo dúvidas sobre como implementar uma página de erro com JSF, e resolvi então criar este post para explicar uma maneira de implementar.

Para se realizar o redirecionamento pode se utilizar o ActionListener do JSF. Segue abaixo um exemplo de implementação da classe deste ActionListener:

/**
 * Classe responsável por tratar erros inesperados do sistema.
 *
 * @author Samuel Delfim
 *
 */
public class ExceptionHandler extends ActionListenerImpl {

    @Override
    public void processAction(ActionEvent event) {
        // Obtem o contexto JSF
        FacesContext context = FacesContext.getCurrentInstance();

        try {
            // Executa o método da classe Pai
            super.processAction(event);

        } catch (Exception e) {

            // Se ocorrer um erro inesperado, exibe a mensagem abaixo
            context.addMessage(null, new FacesMessage(
                FacesMessage.SEVERITY_FATAL, e.getMessage(), null));


            // Redireciona para a pagina com o mapeamento 'erro'
            // no faces-config.
            context.getApplication().getNavigationHandler().
                    handleNavigation(context, null, "erro");
        }
    }
}

Pode-se, por exemplo, na classe acima realizar tratamentos diferentes para cada tipo de exceção.

Para aplicar o Listener em uma aplicação jsf deve ser colocado o seguinte trecho dentro do arquivo faces-config.xml:

<application>
    <!-- Aplicação do Listener -->
    <action-listener>com.thinkworks.handler.exception.ExceptionHandler
    </action-listener>
    <view-handler>com.sun.facelets.FaceletViewHandler</view-handler>
    <locale-config>
        <default-locale>pt_BR</default-locale>
        <supported-locale>pt_BR</supported-locale>
        <supported-locale>es_AR</supported-locale>
    </locale-config>
    <message-bundle>com.bionexo.mensagens.Mensagens</message-bundle>
</application>

O trecho a ser copiado se refere à tag e deve ser aplicado ao view-handler específico. Neste caso, o ViewHandler utilizado é o do projeto facelets que está sendo utilizado no projeto em questão.

Também no arquivo faces-config.xml deve ser realizado o mapeamento da página de erro.
Segue abaixo um exemplo de mapeamento de página de erro:

<navigation-rule>
    <navigation-case>
        <from-outcome>erro</from-outcome>
        <to-view-id>/pages/erro/paginaErro.xhtml</to-view-id>
    </navigation-case>
</navigation-rule>

É isto aí pessoal. Espero ter ajudado...

Configurando o EhCache como cache provider JPA

Olá pessoal,

Hoje vou falar um pouco sobre o EhCache e em seguida mostrarei como configurar o ehcache como provider de cache para o JPA.

Algumas vezes precisamos criar caches para linhas de banco de dados mais acessadas. Entre os problemas para a criação de um sistema de cache temos o sincronismo, o gasto excessivo de memória, o tamanho máximo do cache, entre outros. Devido à grande quantidade de possíveis problemas, escrever um sistema de cache eficiente, seguro e com suporte a sistemas distribuídos é um grande trabalho.

Este é o trabalho do cache de segundo nível do Hibernate (Second level Cache). É possível utilizar este cache com vários providers e um dos mais utilizados é o EhCache. O EhCache é um mecanismo de cache distribuído em Java vastamente utilizado. Ente seus principais recursos temos cache de entidades, de queries, de páginas web, entre outros.

Sua ultima versão está disponível em http://ehcache.sourceforge.net/.

Para configurá-lo como provider de persistência devemos primeiramente adicionar o seguinte trecho ao arquivo persistence.xml:

<property name="cache.use_second_level_cache" value="true" />
<property name="hibernate.cache.provider_class"  
value="net.sf.ehcache.hibernate.EhCacheProvider" />
<property name="net.sf.ehcache.configurationResourceName"
 value="/META-INF/ehcache.xml" />

Depois devemos criar o arquivo ehcache.xml dentro do diretório META-INF da sua aplicação e adicionar nele o seguinte conteúdo:

<?xml version="1.0" encoding="UTF-8"?>
<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:noNamespaceSchemaLocation="ehcache.xsd">
 <diskStore path="java.io.tmpdir" />
 <defaultCache maxElementsInMemory="10000"
       eternal="false"
       timeToIdleSeconds="120" timeToLiveSeconds="180"
       overflowToDisk="true" diskPersistent="false"
       diskExpiryThreadIntervalSeconds="120"
       memoryStoreEvictionPolicy="LRU" />
</ehcache>

Um exemplo mais completo de arquivo de configuração do ehcache pode ser encontrado em http://ehcache.sourceforge.net/ehcache.xml.

Lembrem-se de adicionar o arquivo ehcache.jar dentro das bibliotecas de sua aplicação.

Depois de configurado então deverá aparecer no log do servidor algo como:

23:16:50,437 INFO  [SettingsFactory] Second-level cache:
enabled
23:16:50,437 INFO  [SettingsFactory] Query cache: disabled
23:16:50,437 INFO  [SettingsFactory] Cache provider:
net.sf.ehcache.hibernate.EhCacheProvider

Depois disto é só começar a utilizar as anotações e o cachê de queries.

Em um próximo post falarei sobre como utilizar o cache de segundo nível com o Hibernate.

Resultado da enquete sobre Servidores de Aplicação

Pela resposta dos visitantes vimos que o JBoss, com 16 votos, é o servidor de aplicação mais utilizado para a linguagem Java. Em segundo lugar, logo atrás na pesquisa com 8 votos vem o servidor da Sun, o Glassfish. O WebLogic da BEA e o Oracle IAS vem com respectivamente 4 e 3 votos

Queria agradecer todos que votaram na enquete. E continuem votando para que possamos saber a opnião de vocês sobre assuntos relacionados a desenvolvimento e arquitetura.

É isto aí pessoal. Em breve teremos mais enquetes.

Dicas de usabilidade para sistemas de busca

Como regra geral segundo Jakob provavelmente você não precisará de um sistema de pesquisas se seu site tiver até 100 páginas. Se seu sistema tem de 100 a 1000 páginas, você precisará apenas de um sistema de busca simples. Acima de 1000 páginas é necessário realmente se investir em um bom sistema de pesquisa.

Na navegação de páginas se perceberam que embora alguns usuários tenham optado por utilizar os sistemas de busca, outros preferiram utilizar os links navegacionais. É importante então seu site prover suporte aos dois tipos de acesso, para que seu site possa ter uma grande quantidade de usuários.

Existe uma lista de razões que fazem com que o usuário tenha a expectativa de que o seu sistema de busca acerte mais do que sites como o Google ou Yahoo. Entre estas razões podemos citar:

• Quantidade de informações em seu site é menor que a quantidade de informações de toda a web.
• O contexto é bem conhecido. Se seu site é de carros seu sistema deve saber que um Jaguar é um carro e não um animal.
• Você sabe quais documentos são mais antigos e os que são de maior relevância para os usuários.
• Você tem controle sobre o vocabulário do sistema.
  

Segundo Jakob metade das buscas possuía menos de 14 caracteres. E 95% utilizam menos de 30 caracteres. Tamanho de 30 caracteres então é recomendado para que os usuários consigam realizar buscas eficazes em seu site.

Com relação a buscas avançadas, estas, só são recomendadas se seu nível de usuário for muito avançado, o que na maior parte das vezes não é verdade. Então a sugestão é evitá-las.

Sobre a página de resultados é importante seguir as diretrizes dos grandes sistemas de busca. Entre elas podemos citar:

• Não há necessidade de numerar os resultados, pois todos os usuários começam a ler do alto.
• Forme uma lista linear de uma busca com o mais recomendado na parte superior.
• Cada resultado de uma pesquisa deve iniciar com um título clicável, seguido por resumo de 2 ou 3 linhas.
• Se nenhum resultado for encontrado avise claramente isto ao usuário.
• Se apenas um resultado for encontrado, não redirecione diretamente para o conteúdo, uma vez que a expectativa do usuário é ter um resultado.
  

É isto aí pessoal. Quaisquer problemas avisem...

Lista de problemas de usabilidade – Parte 5

Continuando a lista de problemas potenciais de usabilidade iniciada no último post temos então:

8. Palavras inventadas – Há mais tempo na bolha da Internet vários sites criavam o seu próprio dialeto e inventavam palavras. Isto era feito com o intuito de instigar os usuários a explorar o site, mas criavam o efeito inverso que era de confundir, além de prejudicar os sistemas de busca.

9. Conteúdo ultrapassado – Informações ultrapassadas sendo dadas como atuais são problemas sérios de usabilidade e prejudicam a confiança dos usuários no site visitado.

10. Inconsistência dentro de um WebSite – Páginas na web devem ser consistentes. Áreas de sites que não se encaixam no padrão visual do restante dão uma má impressão ao usuário, além de gerar certa confusão.

11. Solicitações prematuras de informações pessoais – Se um estranho te abordasse e perguntasse a você seu nome, telefone, cpf, data de nascimento e identidade provavelmente você fugiria. Esta é a impressão que se passa quando um site pede seus dados prematuramente. A maioria dos sites agora deixa você realizar suas ações como pesquisar produtos, preços, entre outros para depois pedir suas informações pessoais, o que garante uma quantidade maior de clientes. Pedir então os dados prematuramente é um problema grave de usabilidade e deve ser evitado.

12. Vários sites – As empresas criavam vários sites para diferentes produtos e para cada um criava endereços diferentes. Isto é um problema de usabilidade, uma vez que não existia integração e a navegação não ficava unificada. Sites unificados auxiliam os usuários a realizar a navegação.

13. Páginas órfãs – Páginas órfãs são páginas que não levam a nada. Se acessar uma você não conseguirá ir a mais lugar algum. Este é um problema quase extinto, mas merece um comentário, pois quando acontece é uma falha muito séria.

É isto aí pessoal. Em breve postarei mais sobre o assunto.

Lista de problemas de usabilidade – Parte 4

Olá pessoal. Acabamos de passar os 10.000 acessos ao site desde que comecei a monitorar os acessos e queria agradecer a todos que acompanham o site. Hoje vamos continuar com a série de problemas de usabilidade começada há algum tempo.

Segundo Jackob Nielsen, treze problemas de design iniciais são menos problemáticos hoje, pois os designers aprenderam a projetar para a Web. Estes continuam a ser problemas potenciais de usabilidade, mas a maioria dos Web Designers aprendeu a utilizá-lo.

Segue abaixo a lista:

1. Plugins de tecnologias de ponta – Os usuários tem medo de executarem algum download na Internet por medo de vírus e tem medo da instalação de novos plugins nos navegadores. Os designers tiveram o bom senso e reconheceram que não podiam forçar os usuários a utilizarem novas tecnologias e começaram a utilizar tecnologias testadas há alguns anos. Uma recomendação então é esperar pelo menos dois anos para utilizar alguma tecnologia nova no site e não forçar o usuário a atualizar qualquer coisa ao acessar seu site.
2. Interfaces 3D com o usuário – Interfaces tridimensionais normalmente são excessivamente difíceis de se utilizar e raramente valem o esforço. O problema básico é que imagens em 3D são exibidas em uma superfície bidimensional (tela) e controladas por um dispositivo bidimensional (mouse). Os usuários passam a maior parte do tempo lutando com a interface em vez de visualizar o produto. Interfaces 3D devem então ser evitadas.
3. Design poluído – Páginas que sobrecarregam os usuários com um conjunto grande de elementos normalmente é pouco utilizado pelos usuários. Elementos em movimento, luzes intermitentes, links pobremente estruturados e textos em excesso devem ser evitados, pois tornam a página muito carregada.
4. Páginas Splash – Páginas Splash são páginas de abertura aparecem em alguns sites antes da verdadeira página Principal. Segundo palavras do próprio Jackob elas devem morrer, pois dão a impressão de que o site se preocupa mais com a sua própria imagem do que com a solução do problema deles.

   Exemplo de página Splash

5. Imagens gráficas em movimento e texto rolável – Os usuários tem cegueira a banners como dito em um post anterior e na web imagens gráficas em movimento e texto rolável são ignorados pelos usuários. Lembrem-se que na Internet se você grita mais alto dá a impressão que não tem nada de importante a dizer.
6. Componentes de interface gráfica personalizados – Botões que não se parecem botões, barras de rolagem personalizadas que não se parecem com barras de rolagem são problemas que tornam o site mais difícil de utilizar. Evitem alterar os padrões já aprendidos pelos usuários da Web.
7. Não expor quem está por trás das informações – O usuário deve confiar no responsável pelo site para que este possa passar a ter uma relação de confiança com o mesmo. Dados como o quem somos presente em alguns sites devem ser colocados e devem responder questões como o principal executivo, a informação correta de contato, a filosofia da empresa e o histórico e marcos.

No próximo post terminaremos a lista de problemas...

Lista de problemas de usabilidade – Parte 3

Continuando a lista de problemas comuns de usabilidade e que tendem a ser menos problemático temos:

1. Listagens de pesquisa de baixa relevância – Depois da navegação a busca é a maneira mais utilizada para acessar o conteúdo. Busca ineficaz é extremamente problemática para os usuários.
2. Multimídia e vídeos longos – A maioria dos videoclipes devem ter duração de menos de 1 minuto para que os usuários prestem atenção neles.
3. Layouts Congelados – Sabemos que os usuários odeiam rolagens horizontais e nós sabemos disto. Então é uma boa idéia colocar os tamanhos de sua página em porcentagem, para que seu layout se adapte a diferentes resoluções.
4. Incompatibilidade entre diferentes plataformas – Uma recomendação geral é esperar entre cinco e seis anos depois da distribuição de uma nova versão do navegador para que você não se preocupe mais com ela. O IE7 foi introduzido em 2006, então provavelmente você terá que suportá-lo até 2012. Verifique a quantidade de usuários que utilizam sua plataforma em diferentes navegadores e verifique quais são os que valem a pena suportar.
   

Abaixo agora iremos mostrar uma lista de problemas que grande parte dos usuários se acostumaram a usar e perderam um pouco da sua importância segue abaixo:

1. Clicabilidade incerta – Alguns sites costumavam oferecer figuras com links escondidos o que não indica claramente ao usuário que aquele é um link. Sempre que você tem que informar ao usuário aonde clicar você tem um problema de usabilidade.
2. Registro – Pedir aos usuários que se registrem antes de realizar qualquer ação no site é uma falha de usabilidade. Isto é causa de negócios perdidos, uma vez que vários usuários não gostam de se registrar.
3. URLs Complexos – URLs complexos prejudicam tanto a usabilidade quanto a otimização de ferramentas de busca. A maioria dos sites tem menos de 1 milhão de páginas e portanto funcionam bem com até 50 caracteres.
4. Menus suspensos em cascata – No passado qualquer elemento dinâmico, já confundia o usuário, mas parece que os usuários se acostumaram com alguns elementos. Evitem menus com mais de um nível, pois alguns usuários ainda tem problemas com menus de vários níveis.
   

É isto aí pessoal. Qualquer problema avisem...

Lista de problemas de usabilidade – Parte 2

Continuando com a lista de problemas descrita por Jakob Nielsen temos então:

• Conteúdo vago ou inútil – Quanto pior as mensagens enviadas por um site, mais os usuários tendem a negligenciar suas mensagens. Conteúdo inútil não apenas irrita as pessoas, como também é a principal causa de vendas perdidas.
• Muito conteúdo e texto não escaneável – Blocos densos de texto causam repulsão por parte dos usuários e sugerem que o trabalho para achar o que se quer é muito árduo.

Como uma lista de problemas que tendem a ser menos problemáticos nos próximos anos, mas que ainda preocupam são:

• Tempo de download lento - Tempo de download lento tende a ser cada vez menos preocupante pelo aumento do número de internets com banda larga, mas ainda preocupa, pois sites lentos continuam como sempre a incomodar.
• Frames – Frames quebram várias diretrizes de usabilidade como a quebra do botão voltar e diferenças entre browsers, o que ainda o torna um problema. O que diminui sua severidade é o fato de cada vez menos sites o utilizarem.
• Flash – Páginas flash também quebram várias diretrizes de usabilidade como o botão voltar, textos escaneáveis, quebra do botão voltar e tempos de downloads lentos. Então o flash deve ser usado com bastante parcimônia.

É isto aí pessoal. Quaisquer problemas avisem...

Lista de problemas de usabilidade – Parte 1

Olá Pessoal,

Problemas de usabilidade ainda são muito comuns em sites. O que Jakob Nielsen verificou é que uma série de problemas antigos continua a acontecer constantemente em novos sites e merecem constantemente atenção.

Entre a lista de problemas sérios de usabilidade temos:

• Lista de links que não mudam de cor quando clicados - Entre os erros mais graves listados estão os links que não mudam de cor quando são clicados. Uma boa diretriz de usabilidade é ajudar aos usuários a descobrir onde os usuários estavam, onde eles estão e aonde eles podem ir. A mudança da cor dos links facilita a entender a localização. Esta diretriz só não precisa ser seguida em sites que a mesma ação deve ser executada várias vezes, como por exemplo, em sites que são sistemas de empresas.
• Quebrar o botão voltar – O botão voltar é o segundo recurso mais utilizado na Web e naturalmente os usuários esperam que eles funcionem como deveria. Quebrar o link voltar atrapalha a navegação e diminui a velocidade dos usuários.
• Abrir novas janelas do navegador – Ao clicar em um link os usuários esperam que novas páginas sejam abertas na página atual. Desapontá-los é um erro de design e não impede que os usuários saiam de seu site. Tentar não perder os visitantes é uma causa perdida se os usuários realmente quiserem sair.
• Janelas pop-up – Hoje janelas pop-up são um mal pior do que era no passado. Os usuários estão cada vez mais irritados com janelas pop-up. O simples fato de existir janelas pop-up já é uma razão para os usuários evitarem o site que as possui. A grande maioria dos usuários fecha a janela pop-up antes mesmo de a janela ter sido completamente carregada.
• Elementos de design que parecem anúncios – Usuários normalmente têm cegueira a anúncios, o que faz com que trechos que se parecem com anúncios nem ao menos sejam vistos. Evite então cores fortes e trechos que se parecem anúncios. Normalmente os usuários não o verão.

Em breve teremos mais posts sobre o assunto.

Aguardem...

Diretriz de usabilidade de rolagem de página

Em um estudo mostrado por Jakob em seu livro de usabilidade, foi mostrado que mais de metade dos usuários de seu experimento não rolou pela página. Somente 42% dos usuários do teste viu algum conteúdo da segunda página. Apenas 14% dos usuários visualizaram  mais de duas páginas.

Segundo o autor uma conclusão que se pode tirar sobre isto é que normalmente os usuários são preguiçosos e ignorantes. Outra conclusão diferente segundo ele é que os usuários estão ocupados e há tantas informações na web que não vale a pena se aprofundar em uma página a menos que ela mostre claramente seu valor.

No estudo, 35% das páginas eram tão curtas que não era necessário rolar por elas. A recomendação então não é que as páginas precisem ser tão curtas, mesmo isto resolvendo o problema da rolagem.

Segue então algumas dicas:

• Tente projetar páginas com menos rolagem e tente mostrar no início da página sua importância para o usuário.
• Mostre informações suficientes na primeira parte da página para que os usuários tenham interesse em ver o que está na parte de baixo.
• Qualquer página mais longa que 2,3 telas corre o risco de ser menosprezada, mesmo por aqueles usuários que tem interesse de rolar a página.

É isto aí pessoal. Em breve enviarei mais dicas.

Como os usuários utilizam a Web

Um detalhe interessante sobre como os usuários usam a Web é como as pessoas utilizam os sites. Em média segundo estudos de Jakob Nielsen os usuários gastam 1 minuto e 49 segundos antes de decidir abandoná-lo e partir para outro. Outro detalhe se refere ao fato dos mesmos usuários, ao decidirem realizar uma tarefa em um site específico, gastarem em média 3 minutos e 49 segundos.

Para escolher o site que usarão para realizar a tarefa específica eles vêem 3,2 sites além do site de busca e ao saírem de um site eles apenas em 12% dos casos voltaram ao mesmo site para realizar a tarefa. Isto mostra como cada vez mais a usabilidade é importante e que a disputa é cada vez maior.

Um dado muito interessante é o fato de a Homepage do site ter sido acessada primeiramente em 40% dos casos enquanto nos outros 60% os usuários acessaram os links profundos.

Com relação à página principal, os usuários gastaram em média 30 segundos para visualizá-la. Nesta página é necessário dizer muita coisa em muito pouco tempo. Entre os objetivos desta página deve-se responder as seguintes perguntas básicas:

1. O site em que eles chegaram.
2. Os benefícios que a empresa oferece.
3. Algo sobre a empresa e seus produtos mais recentes.
4. As opções para os usuários chegarem às seções mais relevantes pra eles.

Nas páginas internas, o estudo mostrou que os usuários gastam em média 55 segundos, o que mostra a vantagem de utilização de links profundos já que o usuário lê substancialmente mais informações. 3 diretrizes foram dadas por Jakob no livro para links profundos.

1. Informe os usuários onde eles estão e como podem prosseguir para outras partes do site. Neste caso é importante o nome ou logotipo da empresa no canto superior esquerdo, um link de um único clique para a homepage e um sistema de busca no site preferivelmente no canto superior direito.
2. Oriente o usuário quanto ao restante do site. Se o site possuir uma estrutura hierárquica utilize um “breadcrumb trail” ou “trilha de migalhas de pão” que são links que permitem que os usuários subam e desçam na hierarquia do site.
3. Não pressuponham que o usuário seguiu um único caminho para chegar a página atual. Talvez os usuários perderam algumas informações na hierarquia.

É isto aí pessoal. Em breve postarei mais diretrizes de usabilidade mostradas no livro Usabilidade na Web.

Livro sobre usabilidade na web

Acabei de ler um livro sobre usabilidade na web escrito por um dos maiores papas da usabilidade atual. Jakob Nielsen e Hoa Loranger conseguiram reunir em um ótimo livro, grandes pecados da usabilidade em sites hoje. Com certeza um ótimo livro e extremamente importante para quem que montar um site ou sistema hoje em dia.

Usabilidade na Web - Projetando Websites com Qualidade

A tradução do livro é ótima e a grande quantidade de exemplos facilita a identificação das falhas nos sites. Terei de montar uma apresentação sobre o livro e postarei ao longo das próximas semanas, alguns tópicos, abordados no livro.

É isto aí pessoal...

Resultado da enquete sobre IDEs Java

Pela resposta dos visitantes vimos que a IDE Eclipse continua sendo a mais utilizada para o desenvolvimento Java. Em segundo lugar na pesquisa vemos que a utilização do Netbeans. Em terceiro lugar vieram empatados o WSAD e o MyEclipseIDE.

Nesta última votação tivemos uma participação mais ativa dos visitantes. Em breve teremos novas enquetes e continuem votando.

É isto aí pessoal.

Interceptadores em EJB3

Acabamos de passar dos 6.000 acessos ao site desde que começamos a monitorar os acessos com o analytics e não poderia deixar de agradecer enviando um post que talvez ajude a quem quer monitorar e realizar log das operações realizadas pelas chamadas ao EJB. Neste post de hoje vamos falar sobre interceptadores em EJB3.

A especificação de EJB3 define o que seriam interceptadores que adicionam a abilidade de interceptar métodos de negócio de Session Beans e de Message Drive Beans.
Segue abaixo um exemplo de um interceptador que foi implementado com o intuito de realizar um log dos métodos de negócio chamados:

/**
* Classe interceptadora que imprime os métodos de negócio
* que estão sendo chamandos durante a execução do programa.
*
* @author samuelmd
*
*/
public class LogJPAInterceptor {

 @AroundInvoke
 public Object logInterceptor(InvocationContext invocation)
      throws Exception {
     Logger logger = Logger.getLogger(LogJPAInterceptor.class);
 
     logger.debug(" ---------------------------- ");
     logger.debug("Chamando método " + invocation.getMethod()
             + " da classe " + invocation.getTarget());

     Object[] objetos = invocation.getParameters();

     if (objetos != null) {
         logger.debug("Métodos com os parâmetros :");
         for (Object objeto : objetos) {
             if (objeto != null) {
                 logger.debug(objeto.getClass().getName() + " : "
                         + objeto.toString());
             }
         }
     }

     logger.debug(" ---------------------------- ");
     return invocation.proceed();
 }
}

A anotação @AroundInvoke indica para o sistema qual o método realizará a interceptação dos métodos de negócio.

Interceptadores podem ser adicionados de 3 maneiras diferentes assim como mostrados abaixo:

• Default. Só podem ser adicionados através do descritor de implantação assim como definido abaixo:

  <assembly-descriptor>
  <!—Interceptadores default -->
  <interceptor-binding>
    <ejb-name>*</ejb-name>
    <interceptor-class>
  com.thinkworks.interceptor.LogJPAInterceptor
    </interceptor-class>
  </interceptor-binding>
  </assembly-descriptor&gt

• Classe. Podem ser adicionados tando pelo descritor de implantação quanto pela anotação @Interceptors ({LogJPAInterceptor.class}) em cima da classe.
  

• Método. Definido pela anotação @Interceptors ({LogJPAInterceptor.class}) em cima da classe.
  

É isto aí pessoal. Mais informações podem ser encontradas em http://docs.jboss.org/ejb3/app-server/tutorial/interceptor/interceptor.html.

Qualquer problema avisem…