Blog do Mister M

O prazo para submissão de palestras para o JustJava 2006 foi estendido até esta sexta-feira. Não perca a oportunidade de palestrar no maior evento Java do Brasil!

Ótima notícia. A primeira versão do Javadoc do Java 5 em português do Brasil está disponível online. Parabéns à equipe do projeto de tradução. Embora a documentação das APIs do Java SE seja apenas a ponta do iceberg do problema muito maior – o acesso completo às informações técnicas necessárias para aqueles que não sabem ler inglês -, essa ponta já é um enorme obstáculo vencido.

Fui aceito no Expert Group da JSR 296 – Swing Application Framework. A idéia é prover um framework minimalista para desenvolvimento Swing e algumas idéias estão muito alinhadas com o genesis, como uma anotação @Action. Espero que o genesis possa cooperar com essa JSR ou se tornar uma implementação open-source dela, assim como aconteceu com o Hibernate. Vamos ver :-D

Com o spam e as ameaças de segurança crescendo diariamente, algumas medidas têm sido adotadas pela maioria dos sites para que estes se protejam. Contudo, muitos usuários “válidos” não podem acessar estes sites devido aos dispositivos de defesa implementados.

Um dos melhores exemplos disso é o CAPTCHA, que a maioria das pessoas conhece e não sabe o nome. CAPTCHA é uma sigla que significa Completely Automated Public Turing test to tell Computers and Humans Apart, i.e., Teste de Turing Completamente Automatizado para Diferenciar Computadores e Humanos. A implementação mais comum – e problemática – é perguntar ao usuário o que está escrito numa imagem, que normalmente está distorcida. O objetivo é impedir que “robôs” escritos para mandar spam não consigam ser bem-sucedidos, mas não é isso que acontece, na verdade.

A questão é que este tipo de CAPTCHA, além de poder ser burlado, simplesmente barra a entrada de diversos usuários nos sites. Sim, pessoas com deficiência visual, como (quase) cegos, daltônicos e afins, usam – e precisam usar – a web diariamente. Para isso, contam com o auxílio de softwares – e de hardware especial, em alguns casos -, que conseguem interpretar textos em páginas e aplicativos, emitindo sons ou algum outro tipo de sinal compreensível pelo deficiente. E se você acha que estas pessoas já não conseguem fazer muita coisa com o micro, é porque você nunca viu como os softwares bem implementados funcionam. Eu já conheci pessoalmente alguns indivíduos com este tipo de problema que eram analistas e desenvolvedores – e muito bons, por sinal.

Existem algumas alternativas, como CAPTCHAs baseados na interpretação de sons ou de instruções textuais, mas que podem limitar as pessoas que possuem dois tipos de deficiência, por exemplo. Por isso, a melhor idéia é não utilizar CAPTCHAs se possível ou prover o maior número de opções possível, disponibilizando ainda uma forma de um usuário deficiente que porventura não consiga acessar o seu site ou aplicativo possa avisá-lo disso. Os deficientes agradecem :-)

Sensacional post sobre como não liderar geeks, embora eu ache que se aplique a qualquer pessoa técnica. Dica do Bruno Borges, vulgo miojo, mais um consultor da Summa.

Foi publicado um artigo sobre como detectar e instalar automaticamente o Java WebStart no site da Sun. Essa funcionalidade está disponível desde o Java 5, mas é desconhecida da grande maioria.

Embora o JWS torne possível a fácil distribuição de novas versões da aplicação, a própria instalação do JWS é um desafio em ambientes não controlados. As técnicas descritas no artigo tornam isto mais fácil.

Para se trabalhar com RMI no cliente usando carregamento dinâmico de classes, é necessário ter um SecurityManager definido na JVM. Todo mundo que já usou (ou brincou) com RMI sabe disso, mas também sabe do inconveniente que é ter de definir um arquivo de permissões e ter que configurá-lo no launcher da aplicação só para fazer testes.

Tive que fazer um teste com isso ontem, mas me ocorreu uma idéia: se as exceções de segurança são lançadas pelo próprio SecurityManager, o que me impediria de fazer isso:

System.setSecurityManager(new RMISecurityManager() {
   public void checkPermission(Permission p) {
   }
});

somente para testes?

Bem, isso funciona e é bastante prático, mas não faça isso numa aplicação de produção. Mais uma lição aprendida ;-)

A maioria dos projetos de desenvolvimento que falham tem prazos impossíveis. E, quando estes prazos são definidos por um departamento comercial ávido de ganhar sua comissão, a razão disso é óbvia. Infelizmente, porém, quando esta responsabilidade está com os desenvolvedores o resultado não é muito diferente. Como mudar isso?

A verdade é que, para que um cronograma tenha o menor desvio possível é necessário conhecer:

• As funcionalidades a serem desenvolvidas a ponto de desmembrá-las em tarefas;
• O cliente, de modo a saber a qualidade, nível de documentação e detalhes que o mesmo pode solicitar da sua aplicação, bem como a sua disponibilidade;
• Os recursos que farão parte do projeto a ponto de saber a produtividade deles em cada tipo de tarefa, bem como sua freqüência de ausências (problemas de saúde, pessoais etc.);

Contudo, a maioria das pessoas diria que não é possível conhecer nenhum dos três. E isso explica por que os prazos quase sempre estouram :-) Na maioria dos casos, realmente não é possível ter essas informações no nível desejado para se elaborar um cronograma que funcione, mas a idéia é chegar o mais próximo possível deste cenário para que o desvio não seja tão grande ou ainda contornar cenários comuns.

Por exemplo, digamos que a documentação e/ou nível de informações a respeito das funcionalidades é escassa demais. Provavelmente, a melhor alternativa seria desmembrar o projeto em dois: um projeto de análise de negócio e outro de desenvolvimento, sendo que o segundo terá um cronograma apenas quando o primeiro for encerrado. Se isto não for possível, o ideal é mostrar ao cliente a necessidade de obter o máximo possível de informações para que o cronograma (e o orçamento) proposto sejam reais. Se nada disto for possível, a última alternativa é analisar outros softwares semelhantes ao que o cliente está solicitando, fazer as estimativas baseadas neles e deixar claro que o cronograma proposto baseia-se naqueles produtos. Isto talvez faça com que o cliente se expresse a respeito do que quer exatamente, reduzindo ou aumentando o escopo e, conseqüentemente, o cronograma.

É extremamente importante ter as funcionalidades divididas em tarefas, pois isso permite alocar horas ou poucos dias a cada “fração” da funcionalidade, gerando uma precisão muito maior da duração da funcionalidade como um todo, além de permitir entender melhor o que pode ser paralelizado ou agrupado de forma a otimizar o cronograma. Ao fazer isto, geralmente percebe-se que as coisas “simples” vão demorar muito mais do que se esperava inicialmente.

O conhecimento do cliente é importante para determinar a extensão das tarefas e da documentação, mas especialmente para duas coisas: restrições tecnológicas e disponibilidade do cliente. É essencial, para se ter uma estimativa correta, saber quais tecnologias poderão ser utilizadas, bem como que tipo de padrões de código e documentação o cliente possui. Esta pode ser a diferença entre o projeto de três meses e o que leva um ano porque os desenvolvedores têm que lutar diariamente contra limitações dos frameworks ou da versão do JDK que usam ou porque têm que produzir grandes quantidades de documentos que têm de ser quase que completamente alterados a cada vez que o código é modificado.

Em quase todos os projetos é necessário obter informações adicionais do cliente à medida que o desenvolvimento é feito ou para que as funcionalidades já implementadas sejam validadas. Isto costuma ser um problema, visto que o cliente normalmente não se considera parte da equipe do projeto nem acha que depende dele o cumprimento do cronograma. Metodologias como XP motivam o envolvimento contínuo do cliente, mas nem sempre o cliente concorda com este grau de comprometimento com o projeto. Nestes casos, é necessário especificar no cronograma em que pontos a participação do cliente será necessária, por quantas horas, bem como os “pontos de parada”, i.e., pontos em que se o cliente não estiver disponível o projeto fica parado e deixar claro que é responsabilidade do cliente compensar tais falhas.

Uma vez que as tarefas do projeto estão definidas e que sabe-se como o cliente irá influenciar o projeto, o próximo passo é determinar a alocação de recursos para que seja possível determinar o tempo de cada uma delas. O modo ideal de se fazer isso é explicar aos próprios recursos as tarefas que você pretende alocar para eles, a fim de verificar se são realmente capazes de executá-las, bem como solicitar deles o tempo previsto para cada uma delas.

Obviamente, muitas pessoas não tem a mínima noção de quanto tempo realmente levam para cada tarefa. Por isso, o papel de quem faz o cronograma do projeto é ter dois números para auxiliar nesta etapa: a estimativa de horas ideais e o fator de desvio do recurso. As horas ideais são as horas que um determinado recurso mais confiável em estimativas diz que são necessárias para realizar a tarefa. Normalmente, o recurso confiável acaba sendo a própria pessoa que faz o cronograma ou alguém mais sênior na empresa. O fator de desvio do recurso refere-se a quantas vezes mais tempo aquele recurso leva para executar uma tarefa. Isto se deve a diferença de conhecimento, grau de concentração, capacidade técnica, taxa de “compartilhamento” de recurso (quando a pessoa é utilizada em outros projetos/tarefas ao mesmo tempo que faz o seu projeto) e outras razões. Obviamente, ambos os números só podem ser obtidos com a experiência e/ou medição de projetos anteriores. Comparando a estimativa do recurso com a sua estimativa, chega-se ao número de horas ideais e, multiplicando-se esse valor pelo fator de desvio, obtem-se o total de horas que o recurso deverá gastar.

A explicação acima leva em conta algo que a maioria dos que fazem cronogramas esquecem: recursos são pessoas e pessoas são únicas. Não existe Recurso Jr, Pleno e Sr; existe sim o José, a Maria e o João, que mesmo sendo todos plenos, por exemplo, gastam tempos diferentes para a mesma tarefa e que, para tarefas diferentes, não mantém a mesma taxa de eficácia.

Uma vez que se percebe isto, percebe-se também o quão difícil é fazer cronogramas quando os recursos são desconhecidos. A técnica das horas ideais ainda precisa ser utilizada, mas o fator de desvio terá também de ser estimado. A melhor forma de determinar o fator de desvio a usar é calculá-lo com base na média do fator de desvio dos recursos que serão possivelmente usado para a tarefa e decidir se deve-se considerar o pior caso, i.e., que o recurso com o maior fator de desvio será utilizado.

Ao final de tudo isso, usando-se uma ferramenta como o GanttProject, você provavelmente vai descobrir que o projeto vai levar muito mais tempo do que você pensava inicialmente. Ótimo, isso provavelmente também significa que agora você chegou a um cronograma realista. :-) Por mais que este não seja o cronograma que você vai apresentar ao cliente, por medo de ele não aceitar o tempo – o que eu não concordo -, é com este cronograma que você tem que calcular os custos, pois é o real.

Espero ter ajudado em alguma coisa ou ter deixado vocês completamente desesperados… :-)

O Google Web Toolkit ainda não fez um mês e já é o novo assunto quente na comunidade Java (ok, excluindo-se quem fala de Ruby). O fato é que nenhuma solução Ajax chega aos pés do que o GWT faz, pelo menos mantendo a simplicidade.

Embora o GWT seja excelente, ainda não é o framework que atende todas as necessidades nesse mundo complicado da web. Falta o modo HTML puro (que o Google possui, mas não disponibiliza no framework). O cenário em que um designer é responsável pelo HTML não é coberto pelo framework. Um modelo de programação POJO e sem grandes limitações ainda está longe de ser implementado.

Na minha utopia para web, você poderia ter apenas um XHTML bem formado, sem nenhuma extensão de schema, ou um HTML base, como no proposto pelo GWT, um POJO com a lógica de display (tratamento dos dados, controle de habilitação/visibilidade de widgets, como o modelo de binding do genesis) e uma classe ou mapeamentos para navegação e configuração de binding. O framework faz toda a mágica para você, assim como o compilador do GWT. Isso é plenamente possível de ser implementado hoje; o único problema é que é relativamente difícil de fazer e consome um tempo razoável. Espero que, em breve, possa concretizar essa idéia.

Temos uma nova oportunidade na Summa, a empresa em que trabalho e onde trabalham também Bruno JavaMan Souza, Cláudio Miranda, Gustavo Nalle, Edgar Silva e outras figurinhas da comunidade Java. Segue a descrição:

• Projeto:
  Desenvolvimento de software, Desenvolvimento de Portais e Serviços Técnicos de Informática.
• Requisitos Técnicos:
  • Experiência comprovada no desenvolvimento de aplicações em Java/JEE
  • Experiência no uso de EJB’s e WebServices
  • Mandatório conhecimento de OO
  • Experiência no uso de Design Patterns
  • Conhecimento de linguagem SQL e Banco de Dados Relacional
• Diferenciais:
  • Experiência no desenvolvimento de Portais
  • Experiência no desenvolvimento de aplicações B2B para o mercado financeiro
  • Experiência com RUP
  • Experiência na utilização da IDE Eclipse
  • Experiência nos produtos da Sun Microsystems (Application Server e Portal Server)
  • Certificação

Aos interessados, por favor, encaminhem seu curriculo no endereço curriculo@summa-tech.com aos cuidados de Thais Fernandes.