O problema não é meu - Parte I

Devo desculpas aos amigos que acompanham este singelo espaço, por não escrever nenhum artigo há muito tempo. Infelizmente isso deve ser comum neste próximo ano. Estou em uma equipe que atua com BPM e estamos implantando este conceito em uma das maiores empresas do Brasil.

Já vinha estudando sobre gerenciamento de processos desde fevereiro deste ano, época da minha primeira passagem pela equipe. Tive uma rápida passagem por ETL e, há dois meses, estou de volta ao BPM. Aprendi muitas coisas neste período, principalmente a lidar com a diversidade de profissionais. E é justamente esse o ponto central desta pequena série. Tenho trabalhado com o ALBPM e com um Java que não é Java, mas é Java. Sim, a coisa é meio confusa. Entretanto, existem aplicações puramente Java que auxiliam o sistema como um todo, como as consultas.

Integrando JSF 1.2 com Richfaces e EJB3 utilizando JBOSS AS 5 e Eclipse - Parte I

Como encontrei pouquíssimas fontes de consulta sobre o assunto em sites brasileiros, resolvi escrever esse artigo que visa exemplificar uma das formas de se integrar com sucesso esses três frameworks em sua aplicação. Foi a solução que implementei em meu projeto e espero que seja de utilidade para outros desenvolvedores que possam estar passando pelos mesmos problemas que eu enfrentei para deixar a aplicação funcionando 100% sem bugs.

Uma amostragem da EJB 3.1 (Tradução)

por Ken Saks

O último update da tecnologia Enterprise JavaBeans (EJB), EJB 3.1, está próximo de ser finalizado. O final draft da especificação já está disponível. O objetivo principal desta nova especificação é simplificar o desenvolvimento usando EJB e adicionar algumas funcionalidades há muito solicitadas, como os singleton beans.

Princípios de projeto - Parte IX - Relacionamento entre classes

Aproveitando o meu post nesta thread do JavaFree.org, vou desenvolver aqui um pouco mais o relacionamento entre classes.

As decisões quanto a esse aspecto, podem levar a sua aplicação a ter um bom ou um mau design. Alguns conceitos, como os que abordam a questão da coesão, são decisivos para uma boa escolha para o relacionamento entre classes.

Como usar Scala no Eclipse

Neste artigo, mostrarei como usar o Eclipse como sua IDE para desenvolvimento em Scala.

Desde o meu post comentando o artigo do James Strachan, meu interesse na linguagem Scala só cresceu. Iniciei meus estudos, como todo bom aprendiz, com um editor de textos. Depois dos primeiros "Hello Words", resolvi buscar uma IDE e encontrei uma forma de usar o Eclipse para desenvolver com Scala. O processo é muito simples.

Requisitos recomendados:

1. Java versão 1.6, update 14 ou superior (versão 5 no mínimo);
2. Distribuição standard do Eclipse 3.5 ou superior.

Instalação: A IDE do Scala para Eclipse é melhor instalada (e atualizada) através do próprio Eclipse.

1. Selecione Help -> Install new software
2. Clique no botão Add Site...
3. Entre com esta URL, http://www.scala-lang.org/scala-eclipse-plugin, na caixa Location
4. Depois de clicar em OK, você deve ver "Scala Eclipse Plugin" como opção de instalação
5. Clique no botão "Install..." e siga as instruções a partir daqui.

Terminada a instalação, você já será capaz de criar projetos Scala no Eclipse.

Veja abaixo um exemplo:

Links relacionados:
Tutorial em inglês: http://www.scala-lang.org/node/94
Site oficial: http://www.scala-lang.org/

Princípios de projeto - Parte VIII - Usabilidade

O blog Portal do Arquiteto publicou recentemente, uma série de cinco artigos que dizem respeito a problemas de usabilidade.

Segundo a Wikipedia:

Usabilidade é um termo usado para definir a facilidade com que as pessoas podem empregar uma ferramenta ou objeto a fim de realizar uma tarefa específica e importante.

E, no nosso contexto, nossos sistemas são as ferramentas. Assim, trazendo para o nossa área:

A usabilidade está diretamente ligada ao diálogo na interface e a capacidade do software em permitir que o usuário alcance suas metas de interação com o sistema. Ser de fácil aprendizagem, permitir uma utilização eficiente e apresentar poucos erros, são os aspectos fundamentais para a percepção da boa usabilidade por parte do usuário. Mas a usabilidade pode ainda estar relacionada com a facilidade de ser memorizada e ao nível de satisfação do usuário.

Nosso objetivo maior, quando estamos participando de um processo de desenvolvimento, é facilitar a vida do usuário. Precisamos que nosso sistema disponha de uma boa usabilidade, do ponto de vista do usuário, para que possamos cumprir esse objetivo.

O termo usabilidade se fundiu com o termo navegabilidade, mais ainda com o advento da WEB.

Seu usuário precisa sentir-se confortável durante os acessos ao seu sistema. Se o acesso aos pontos de interesse for dificultado, o sistema perde a credibilidade.

Quando estamos desenvolvendo sistemas específicos para uma empresa ou para um grupo de usuários que nos contratou, nossa busca pela excelência na usabilidade fica facilitada. Entretanto, quando nosso foco é geral, como uma loja online, por exemplo, o trabalho fica um pouco mais difícil. Nesses casos, a busca por uma boa usabilidade depende de uma eficiente pesquisa de opinião, pesquisa essa que o usuário nem sempre está disposto a responder.

Na maioria dos casos, se o usuário não se sente confortável em seu site, ele simplesmente o abandona e procura outro que o atenda perfeitamente em suas necessidades. Assim, essa pesquisa de opinião deve ser realizada, também, por pessoas de nosso conhecimento, capacitadas a testar nosso trabalho.

Em grandes empresas, normalmente, existe uma equipe de testes específica para tratar de casos como a usabilidade, baseando-se nos requisitos dos clientes.

Um princípio que aprendi nesses meus anos de experiência como desenvolvedor é: quem desenvolve não está apto a testar a usabilidade.

Por que?

• Em primeiro lugar, porque a equipe que desenvolveu o sistema, normalmente, conhece todos os caminhos (e atalhos) do sistema e está viciado em uma navegação que sempre funciona.

• Em segundo lugar, não desenvolvemos sistemas para nós e sim para o usuário/cliente. Então quem precisa avaliar se o sistema é utilizável de forma eficiente ou não é o usuário e não a equipe de desenvolvimento.

Tenhamos sempre em mente a usabilidade, pois se um sistema é complicado de ser usado pelo usuário, para que existir sistema?

Parte I - Introdução
Parte II - Correção
Parte III - Design por contrato
Parte IV - Flexibilidade
Parte V - A Lei de Demeter
Parte VI - Eficiência
Parte VII - Coesão
Parte IX - Relacionamento entre classes

Scala vai substituir o Java?

James Strachan, em seu blog, levanta essa questão interessante. Interessante, também, como a necessidade de substituir o Java tem tomado proporções incríveis na mente de algumas pessoas. Ruby, Scala, e muitas outras opções tem aparecido como alternativas mais simples ao Java.

E é justamente com a complexidade do Java que James começa o seu texto. James alega que a especificação do Java é muito complexa (600 páginas), falando de autoboxing, generics e diversas alternativas que Java oferece.

Eu, particularmente, no último Falando em Java, tive a oportunidade de ver o Fábio Kung desenvolvendo, "ao vivo", um programinha em Ruby para sortear números aleatórios. A lógica foi desenvolvida em uma linha (ou duas, pois a linha não coube na tela). Entretanto, para entender essa "única" linha, você precisaria entender diversos aspectos da linguagem. Ora, não é a mesma coisa que ocorre em Java? Não vejo vantagens em tudo ser escrito em apenas uma linha, só aumenta a complexidade para a leitura. E programadores Ruby o que diriam? É só se acostumar.

É óbvio que meu estudo sobre o Ruby está apenas no início, mas até o momento, ainda não vi esse "estouro de produtividade" prometida.

James continua seu texto falando sobre linguagens dinâmicas e dando a sua visão de porque o Scala substituiria o Java a longo prazo.

Acho interessante o estudo de diversas linguagens para que seu horizonte seja ampliado, para que o estudo de uma outra linguagem ajude o desenvolvedor a melhorar as suas práticas, para que você tenha mais opções no momento de atacar um problema.

Enfim, o que me tira do sério é o uso descabido da palavra replacement, como se uma outra linguagem fosse a tão falada bala de prata.

Como sempre digo aqui neste blog, bala de prata existe tanto quanto existem lobisomens.

Programação em par defendida pelos números

É muito interessante notar a reação das pessoas quando tentamos introduzir a idéia da programação em par. A primeira reação, normalmente é:

Porque devo colocar duas pessoas para fazer o trabalho de uma?

Este argumento, em primeira vista válido, não passa de uma avaliação superficial do que realmente ocorre em um processo de desenvolvimento. A maioria das pessoas acredita que o processo de desenvolvimento seja, em sua essência, escrever código. Mas, não é. Na verdade, escrever código é a menor parcela neste processo. A maior atividade neste processo é pensar.

Quem já tem alguma vivência no mundo do desenvolvimento, sabe que quando colocamos a mão no código, já temos algo em mente que precisa ser implementado. Não estou me referindo a UML, análise antes de implementar ou waterfall. Antes de escrever qualquer linha de código você deve (ou deveria) saber porque está escrevendo aquilo, isto é, quais são seus objetivos. Antes de escrever essa primeira linha, você já tem uma idéia da lógica que será usada.

Nesse ponto, é possível provar a importância da programção em par, pois é onde temos o maior risco de decisões ruins e inserir erros. Estes erros irão custar tempo de desenvolvimento no futuro. E tempo é dinheiro.

O grande valor da programação em par está na possibilidade de pequenas correções de curso, e eliminação de erros logo assim que eles aparecem. Esses erros podem ser sutis e um overlook do par pode impedir que sigam adiante possibilitando, dessa forma, a correção prematura, permitindo a empresa economizar muito dinheiro com esforço em manutenções futuras.

O quanto é esse muito?

Quando estamos lidando com dinheiro, precisamos quantificar com precisão o que está envolvido. E, Dave Nicolette, fez isso de forma brilhante neste artigo, baseado em sua experiência. No artigo, ele mostra com números, a realidade de uma empresa que adota a programação em pares no seu dia-a-dia.

Sites relacionados:
InfoQ

Eclipse Galileo disponível para download

A release anual do Projeto Eclipse - Galileo - já está disponível para download. Como bom fã que sou, já estou testando a RC4 há uma semana e, até onde pude avaliar, a versão está bem interessante. Nesse pequeno período, as diferenças mais significativas que notei foram a possibilidade do "column mode" (block selection) e o code completion me pareceu mais inteligente. A release oficial vai se tornar, também, a minha IDE oficial a partir de hoje, e, conforme eu for notando novidades que impactam meu dia-a-dia, compilo e posto aqui. Link para donwload: http://www.eclipse.org/downloads/

EDIT: Este blog - EclipseSource - possui um interessante Top 10 das funcionalidades do Eclipse Galileo.

A importância da qualidade - Estudo de Caso - Itaú e a Internet

Sou cliente do Itaú há quase uma década. Dificilmente preciso ir à alguma agência, pois resolvo todos os problemas online. Normalmente, a qualidade do serviço é satisfatória, mas nesta oportunidade, que mostrarei aqui, deixaram a desejar.

A grande motivadora desta introdução foi uma conversa que tive com o consultor Mário Bacellar sobre como os serviços online estão se tornando onipresentes nas nossas vidas. Como eu disse na introdução desse post, eu não vou mais a agencias bancárias. Por que? Porque resolvo tudo online. A Internet alterou o nosso conceito de tempo e espaço. Não precisamos mais esperar o programa esportivo para vermos os gols da rodada. Podemos assisti-los online. Não precisamos mais enfrentar filas ou ficar restringido ao horário bancário para pagar uma conta, fazemos isso online.

Com os serviços online ficando corriqueiros, quase atingindo a banalização, a demanda por profissionais cresce. O crescimento da demanda por profissionais traz junto a demanda por cursos especializados e cursos superiores para formação destes profissionais. E é aí que mora o perigo. Muitos cursos formam profissionais "meia-bomba" que, consequentemente, são mais baratos. Muitas empresas querem estes profissionais baratos. Motivos? Das duas uma: ou não se importam com a qualidade, ou acham que qualquer desenvolvedor fundo de quintal possa fazer uma aplicação de qualidade. E o resultado? Esse abaixo:



Uma instituição com o Itaú não pode jogar um stacktrace na cara do cliente. No máximo, dar uma mensagem de serviço indisponível.

A excelência em qualidade de software é complicada de ser alcançada. Normalmente, os cursos superiores não estão preocupados com essa questão. O desenvolvedor precisa ser inquieto e melhorar neste quesito por conta própria, com livros e cursos mais especializados.

Por outro lado, as empresas devem buscar e valorizar profissionais com esse perfil. Devem estar sempre atentas, para identificar entre os seus funcionários, os que mais se enquadram nas políticas de qualidade da empresa. Após identificado, esse funcionário deve ser estimulado a manter sua ambição pela excelência e incentivado com cursos e eventos pagos pela empresa.

Casos como esse ocorrido com o Itaú, arranham a imagem de uma instituição. Se esta não estiver com uma base sólida, a perda de credibilidade do usuário do serviço pode levar a organização a falência.

Devemos ficar atentos e valorizar sempre a excelência na qualidade.

EDIT: Só deixando claro que a crítica não é somente sobre o profissional de desenvolvimento, e sim sobre o processo como um todo. Um código não pode passar pela homologação e entrar em produção cuspindo um stacktrace. Alguma coisa está errada em algum lugar.

AdSense e HotWords - Gerando receita - A realidade

Estive analisando o AdSense mais detalhadamente, vendo este vídeo e este fórum.

O sistema possui um background inteligente com leilão e diversos critérios de seleção de anúncios.

O vídeo apresenta as melhores técnicas para localização e layout dos anúncios. Apresenta a teoria do F, mostrando os locais da tela que recebem maior atenção dos usuários. Também explica o inventário de anúncios, eCPM e CTR, mostrando que o valor do clique está relacionado a quanto paga o anunciante, mostrando o posicionamento correto de anuncios que possuem o maior potencial de receita.

No blog também utilizo o HotWords, que não ocupa espaço, utilizando o próprio texto das postagens. O processo de cadastramento foi muito fácil e rapidamente as HotWords já estavam aparecendo.

Ambos procuram o anuncio que melhor se relacionam com seu site. O HotWords envia o click para uma nova janela, o AdSense abre na mesma.

Política de Privacidade

Este site pode utilizar cookies e/ou web beacons quando um usuário tem acesso às páginas. Os cookies que podem ser utilizados associam-se (se for o caso) unicamente com o navegador de um determinado computador.

Os cookies que são utilizados neste site podem ser instalados pelo mesmo, os quais são originados dos distintos servidores operados por este, ou a partir dos servidores de terceiros que prestam serviços e instalam cookies e/ou web beacons (por exemplo, os cookies que são empregados para prover serviços de publicidade ou certos conteúdos através dos quais o usuário visualiza a publicidade ou conteúdos em tempo pré determinados). O usuário poderá pesquisar o disco rígido de seu computador conforme instruções do próprio navegador.

Usuário tem a possibilidade de configurar seu navegador para ser avisado, na tela do computador, sobre a recepção dos cookies e para impedir a sua instalação no disco rígido. As informações pertinentes a esta configuração estão disponíveis em instruções e manuais do próprio navegador.

Novo Blog

O blog está de roupa nova, mas o conteúdo é o mesmo. Continuarei a falar de engenharia de software e não virarei crítico musical.

Há cerca de três semanas notei a necessidade do blog possuir 3 colunas. Neste feriado, consegui um tempinho e passei a madrugada reformulando a cara do blog. Testei alguns templates, perdi alguns gadgets e consegui esse resultado que achei interessante. Agora vou recolocando os gadgets aos poucos.

As cores são sóbrias, o template é altamente customizável e a informação fica com uma distribuição interessante.

Espero que gostem e se não gostarem podem comentar.

Object-Oriented Software Construction do Bertrand Meyer.

Acabei de adquirir o livro Object-Oriented Software Construction do Bertrand Meyer.

Tenho as melhores recomendações sobre esse livro e tenho pena de não ter lido a mais tempo. Todos os feedbacks apontam como obra obrigatória para qualquer engenheiro de software.

Comprei o livro na Amazon, por um preço ótimo (cerca de $63.00).

Este é o próximo livro da minha fila e já estava ficando irritado com o gap formado entre o Fundamentals do Page-Jones, minha ultima leitura, e o do Meyer a próxima.

Não vejo a hora de chegar meu brinquedo novo.

Princípios de projeto - Parte VII - Coesão

Já conversei com algumas pessoas que utilizaram esta frase, "receita de bolo", quando eu perguntei o que significava, um bom design OO:

Baixo acoplamento e alta coesão.

Mas, o que é coesão de classe?

Este artigo é totalmente baseado no livro Fundamentals of Object-Oriented Design in UML, do Page-Jones.

Coesão de classe é a medida da inter-relação dos recursos (atributos e operações) localizadas na interface externa de uma classe. Page-Jones, diz que o termo coesão de tipo seria uma definição melhor, já que o conceito que está sendo passado aqui é: quão bem uma classe funciona como uma implementação de algum tipo de dado abstrato.

Ainda segundo Page-Jones, uma classe com baixa (ruim) coesão tem um conjunto de recursos que não estão em harmonia entre si. De outro modo, uma classe com alta (boa) coesão, tem um conjunto de recursos onde todos contribuem para a abstração de tipo implementada pela classe.

Algumas pessoas tem tentado definir coesão de classe considerando como os métodos usam os atributos internos. Entretanto, Page-Jones não gosta dessa definição por dois motivos: O primeiro é que a coesão de classe deve ser percebido de fora de uma unidade de software; o segundo é porque a coesão pode mudar de acordo com mudanças na classe durante o seu ciclo de vida, isto é, uma classe imatura pode parecer ter menor coesão que uma classe mais madura.

Page-Jones observou 3 problemas principais na alocação de recursos numa classe: mixed-instance, mixed-domain e mixed-role. Os problemas estão listados em ordem de relevância, sendo a mixed-instance o maior problema e mixed-role o menor.

Uma classe sem esses três problemas de coesão é inteiramente coesiva e pode-se dizer que possui uma coesão ideal.

Vamos as definições.

1. Mixed-instance: Uma classe com mixed-instance cohesion possui alguns recursos que não são definidos para alguns objetos da classe. Ex: em um departamento de vendas, existem vendedores comissionados e não comissionados. Uma classe Vendedor possui o método pagarComissao(). José é comissionado e Maria não. Poderíamos até setar a comissão de Maria para zero. Entretanto, isso não seria verdade, já que Maria não tem zero de comissão. Poderíamos criar um atributo boolean que indicaria se o vendedor é comissionado, mas isso seria um péssimo design. A solução mais elegante seria criar uma classe VendedorComissionado e VendedorNaoComissionado;
2. Mixed-domain: Uma classe com mixed-domain cohesion contém um elemento que sobrecarrega a classe com uma classe extrínseca de um domínio diferente. Uma classe A é extrínseca de B se A puder ser totalmente definida sem noção de B. Ex: Uma classe Real possui um método arcTan. Mas arcTan não é um recurso de Real e sim de Angle. Quando você está modelando uma classe de um dado domínio, você só poderá incluir classes dos domínios inferiores. É o que define reusabilidade.
3. Mixed-role: Uma classe contém um elemento que faz parte do domínio, mas não faz parte da abstração dessa classe. Ex: Uma classe Pessoa possui um método qtdCachorros(). Só que Cachorro, na verdade, não faz parte de Pessoa. Como você reusaria Pessoa se não houver Cachorro na nova aplicação? E se continuássemos com essa filosofia de design? Onde pararíamos? qtdBarcos(), qtdGatos(), qtdCarros(), etc. Todos esses atributos sobrecarregam a classe Pessoa. É muito simples cair nesse tipo de problema de coesão, pois: 1- É muito fácil escrever uma mensagem para descobrir quantos cachorros uma pessoa tem, simplesmente fazendo jose.qtdCachorros(); 2- Muitas abordagens de design indicam que qtdCachorros() é um método de Pessoa; 3- Na vida real, se você quiser saber quantos cachorros José tem, você perguntaria a ele. Uma solução para esse problema seria criar uma classe intermediaria, entre Pessoa e Cachorro, que mapaearia a quantidade de cachorros que uma pessoa possui. Problemas de mixed-role cohesion reduzem a reusabilidade de uma classe, fique atento.
   

Evitando estes problemas coesão, estaremos modelando nossas classes com qualidade, facilitando a manutenção e futuras implementações (reusabilidade).


Parte I - Introdução
Parte II - Correção
Parte III - Design por contrato
Parte IV - Flexibilidade
Parte V - A Lei de Demeter
Parte VI - Eficiência
Parte VIII - Usabilidade
Parte IX - Relacionamento entre classes