quinta-feira, 25 de junho de 2009

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

quarta-feira, 24 de junho de 2009

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.

quinta-feira, 18 de junho de 2009

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.

quarta-feira, 17 de junho de 2009

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.

terça-feira, 16 de junho de 2009

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.

sexta-feira, 12 de junho de 2009

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.

quarta-feira, 10 de junho de 2009

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.

segunda-feira, 8 de junho de 2009

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

sexta-feira, 5 de junho de 2009

Kent Beck - Design Responsável

Kent Beck e Martin Fowler, são, para mim, as maiores expressões do mundo da Arquitetura de Software - Software Design, atualmente. Nesta apresentação, Beck compartilha conosco as suas idéias de um design responsável.
EDIT: Esclarecendo que responsável não é a tradução de responsive (título original da apresentação). Resolvi utilizar responsável no lugar de responsivo por achar que traz um sentido melhor, sem deixar de expressar a idéia central da apresentação. Acredito que um design "responsivo" possa ser um "subproduto" de um design responsável.
Beck, o pai do JUnit e da XP, inicialmente, fala sobre Steady Flow of Features. Estabeleceu que o design deve ocorrer no tempo certo. Se muito cedo, quando novas features chegarem, será até possível implementar as primeiras, mas vai acabar criando um gargalo, quando novas features chegarem. Em contrapartida, se muito tarde, haverá tanta coisa para fazer que a implementação ficará impossível.

Em uma apresentação irrepreensível, mostra que desenvolvimento de software é Beneficially Relating Elements. Elementos de software, relacionando-se para gerar benefícios. Com base nisso, Beck fala sobre um pequeno conjunto de estratégias utilizado por ele no design de software: Leap, Parallel, Stepping Stone e Simplification.

Apresentação obrigatória a todos que estão preocupados com a excelência no design de softwares, Beck nos mostra como deve ser o pensamento de um profissional da nossa área.

Bom proveito.

Sites Realcionados:
Apresentação

terça-feira, 2 de junho de 2009

[Notícia] Chega de Notícias

É isso mesmo.

Atendendo a um gentil convite do Dalton Camargo, publicarei as notícias que achar relevante no JavaFree.org, a partir de hoje. Essa é a última notícia publicada aqui.

Achei interessante essa divisão e espero que seja o início de uma parceria longa e proveitosa para a comunidade em geral.

Notícias no JavaFree.org: http://www.javafree.org/noticias/

segunda-feira, 1 de junho de 2009

[Notícia] Java Mobile, Media & Embedded Developer Days no Brasil

O Brasil sediará a primeira edição do Java Mobile, Media & Embedded Developer Days realizado na América Latina. O evento será realizado em Goiânia, no dia 20 de junho.

O evento reunirá desenvolvedores de dispositivos móveis e embarcados e, na minha opinião, a parte mais importante falará sobre o Java e a Tv Digital.

O evento no Brasil está sendo organizado pela Comunidade Java de Goiás (GoJava) em parceiria com a Robótica Livre de Goiás e Associação de Software Livre de Goiás (ASL-GO). A Sun Microsystems está patrociando e apoiando.

Os temas serão: JavaME, SunSPOT, Tv digital, Blu-ray, Bluetooth, Java Card, LWUIT, Robótica Livre, Tecnologias Embarcadas e JavaFX Mobile.

Infelizmente, não poderei comparecer a este evento.

Sites Relacionados:
Info Abril
Site do Evento

[Notícia] AMD introduz Opteron de seis núcleos

Nova geração da AMD promete ganhos de até 34% por watt sobre a geração anterior. O lançamento está previsto para a segunda metade deste ano. The Tech Report
AUSTIN, TEXAS — With Intel's Nehalem-based Xeons gathering like a storm on the horizon, AMD today gave the first working demonstration of its potential counterpunch: a six-core Opteron processor code-named "Istanbul." Istanbul is a fairly straightforward upgrade over current 'Shanghai' Opterons: a 45nm processor with 6MB of L3 cache that fits into a Socket F-style motherboards, only with six cores rather than four. As a result, the upcoming Istanbul-based Opterons will serve as drop-in upgrades for existing Socket F systems. The chips will take advantage of the same 2P, 4P, and 8P infrastructure as today's Opterons, with HyperTransport and two channels of DDR2 memory per socket.
Sites relacionados: Info Plantão The Hardware Extreme Tech Report

Princípios de projeto - Parte VI - Eficiência

Algumas pessoas preferem o termo eficácia para definir o que vou escrever agora. Não pretendo entrar nessa discussão. O objetivo é falar de código que cumpra os requisitos usando menos recursos (processador, memória, etc.) possível. Dessa forma, usarei a palavra eficiência para expressar esse sentido. O próprio Aurélio trata os termos como sinônimos e a grande maioria dos sites que encontrei diferenciando-os, estão relacionados com administração de empresas.

Este é o princípio mais importante quando desenvolvemos
Real-Time Applications. Quando não estamos trabalhando com este tipo de aplicação, este é o primeiro a sofrer degradação para que o código atenda a outros princípios. Entretanto, existem códigos eficientes que não precisam ser degradados.

A matemática nos fornece meios para tornarmos algumas soluções mais eficientes. Um exemplo de código eficiente é o usado para somar os números de 1 a n. Uma técnica matemática.

Alguns podem pensar: "Ué, é só fazer um for de 1 a n, somando um contadorzinho idiota!". Quem está pensando nisso não conhece Mr. Carl Friedrich Gauss.

Gauss encontrou, durante uma aula de aritmética, a propriedade da simetria das progressões aritméticas, derivando a fórmula da soma para uma progressão aritmética arbitrária – fórmula que, provavelmente, Gauss descobriu por si próprio.

Chega de papo e voltemos a eficiência de código.

Imagine que no seu sistema exista uma funcionalidade que some os números de 1 a 1.000.000.000.000.

Já é possível notar que um laço for seria dispendioso. Para essa situação, Gauss vem em nosso socorro, com sua fórmula da soma para uma progressão aritmética: Sn = (n * (A1 + An)) / 2.

Utilizando a fórmula, seu código estará mais eficiente que um código utilizando um laço for. Estaremos consumindo menos recursos de hardware e nosso sistema responderá muito mais depressa.

Este foi um exemplo de eficiência que não precisa ser degradado para o atendimento de qualquer outro princípio, como a legibilidade.

Outras técnicas que necessitam de uma preocupação maior com a eficiência são as técnicas de classificação (Bubble Sort, Tree Sort, etc). Quando usamos estas técnicas, buscamos eficiência. Não é raro encontrar milhares e até milhões de dados precisando de ordenação. Um algoritmo ineficiente, comprometerá demais a perfomance da aplicação. Nestes casos, a eficiência sobe na escala da prioridade, ficando abaixo apenas da correção e da robustez.

Quando estamos usando um framework, devemos conhece-lo profundamente, a fim de não degradarmos a eficiência da nossa aplicação por motivos de falta de conhecimento. Se a eficiência é uma preocupação, devemos conhecer profundamente como configurar o(s) framework(s) escolhido(s), assim como conhecer as classes que nos darão ganho de eficiência. No último Falando em Java, técnicas de otimização do Hibernate foram apresentadas. Veja aqui.

Sites Relacionados: http://pt.wikipedia.org/wiki/Teoria_dos_n%C3%BAmeros
http://www.educ.fc.ul.pt/docentes/opombo/seminario/gauss/gauss.htm
http://wapedia.mobi/pt/Teoria_dos_n%C3%BAmeros
http://hypescience.com/10-simples-truques-de-aritmetica/


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