quinta-feira, novembro 30, 2006

Dependências entre Controles : Parte 1

Este é o primeiro de uma série de três posts, nos quais eu falarei sobre dependência de controles nas telas de cadastro.
Nessa colocação inicial, darei uma visão geral do problema e como ele é resolvido no braço. No segundo, vou mostrar como alguns frameworks encaram essa situação. No terceiro e último, é apresentada a proposta do Merlin. Depois de lerem, não hesitem em dar suas opiniões e sugestões.

NOTA: A dependência de controles envolve muitos tipos de elementos de interface (como caixas de texto, seleção, marcação, textos estáticos, etc.) e por isso, para ser mais objetivo, vou tratar de dependências entre caixas de seleção, ou comboboxes. Escolhi elas por dois motivos: primeiro, porque representam elementos de complexidade intermediária se comparados com outros objetos existentes na interface do usuário e, segundo, porque elas a estão há tempo pipocando na minha cabeça, pedindo para serem armazenados em um meio durável, hehehe.

Dependência entre controles, um exemplo
No projeto de formulários, é dito que existe uma dependência entre controles quando o conteúdo ou o estado de um (ou mais) controle(s) depende do conteúdo ou estado de outro(s) controle(s). Essa é uma definição que eu criei, porque não lembro de ter visto algo melhor nos livros que já li.
Para ficar mais claro, veja essa figura:

Essa tela representa o cadastro de uma pessoa,
a qual mora em uma cidade que, por sua vez, pertence a um estado (ou Unidade Federativa - UF). Aqui, o objetivo é simples: ao selecionar um estado, espera-se que a caixa de seleção das cidades exiba somente as cidades que pertencem ao estado selecionado.
Para implementar esse comportamento, a abordagem tradicional, via código, é a seguinte:
  1. Ao carregar o formulário (evento onShow, por exemplo), é carregada a caixa de seleção estado, colocando como valor padrão nenhum ou aquele mais apropriado para o usuário (tal como o projetista definiu). Esse carregamento nada mais é do que um comando de seleção de registros no banco de dados sobre a tabela de estados. A caixa de seleção da cidade está (1) ou sem nenhum dado carregado e nem selecionado ou (2) está carregada com (2.1) os estados pertencentes ao estado previamente carregado com uma cidade padrão selecionada, ou (2.1) sem nenhuma cidade padrão selecionada, ou (2.3) está carregada somente com uma cidade, que é a cidade padrão e esta está selecionada. Variações nesse modelo podem ocorrer, mas o comportamento essencial é esse.
  2. No evento onChange da caixa de seleção do estado ocorre um processamento que seleciona no banco de dados (ou em um cache local) as cidades que pertencem ao estado que acabou de ser selecionado. Dependendo do que o projetista definiu, quando isso ocorre, a caixa de seleção da cidade pode ficar com (1) um valor padrão para o estado selecionado ou (2) ficar posicionada em nenhum.
  3. Modificações na caixa de seleção da cidade não implicam em nada.
No tocante aos dados exibidos nessas caixas de seleção, observa-se os atributos mais comumente reconhecidos pelo usuário, tais como (1) para cidades, o nome e (2) para estados, a sigla ou o nome. Novamente, depende do projetista :-)

As dificuldades
Quanto à complexidade disso, o tipo de processamento a ser executado (regra de negócio) é bastante simples. Tanto que, em algumas IDEs (como o Delphi) existem controles específicos para essa funcionalidade, os quais entram em funcionamento com alguns ajustes de configuração e/ou pequenos trechos de código adicionais. Quando não existente, esse comportamento geralmente é implementado na íntegra pelo programador e reside (quando muito!) em classes utiltárias e genéricas, de forma que possa ser reutilizado quando necessário. Programadores mais avançados (e com tempo de sobra) criam códigos bastante complexos, performáticos e (duvidosamente) estáveis, os quais são empacotados em componentes da casa e reutilizados (expostos?) como obras de arte em vários sistemas. Não obstante, é comum esses componentes terem suas limitações exarcebadas somente quando muito tempo passou desde seu projeto e as consequências para manutenção acabam revindicando todo o tempo que fora "ganho" antes...
Sem considerar esses aspectos (que seguramente muitos desenvolvedores irão me questionar), existe um problema muito mais impactuante e de uma transparência tamanha que passa despercebida pela quase totalidade dos desenvolvedores: retrabalho.

Retrabalho x reuso
Reuso é o ato de utilizar novamente algo que já foi utilizado. É como aquele programador que diz: Pô, para isso eu já tenho uma classe que resolve. É só instanciar esse objeto, chamar aquele método e configurar esses parâmetros que está pronto! Isso é o reuso. E todos amam essa palavra, principalmente quando ele funciona.
Retrabalho é o que o programador acima acabou de fazer. Ele já tinha a solução pronta, mas teve que aplicá-la novamente no novo problema que surgiu.

De certo, muitos vão perguntar: Mas isso é mais do que óbvio. Toda vez que eu tenho um mesmo problema, eu "pego" a solução que já possuo e aplico ela novamente!

E eu, com minha visão pessimista, vou dizer: Isso tá muito trabalhoso ainda! Eu quero uma solução reutilizável, mas que não implique em retrabalho. Tu não tens uma?

Talvez...vamos dar uma olhada na caixa de ferramentas...
[continua]

segunda-feira, novembro 27, 2006

BabelFish Translate: Quero um botão para reverter a tradução

Não entendo muito de inglês e por isso uso frequentemente o BabelFish Translator (que eu considero melhor do que o Google, infelizmente).
Faz tempo que queria comentar isso e agora tive tempo, então lá vai...
Muitas vezes, traduzo um texto de português para inglês (ou o contrário) e o resultado, quando não "soa bem" eu tento traduzir novamente, agora na ordem inversa. Explico:

Traduzo: Texto em português para Text in portuguese. Daí traduzo Text in portuguese para Texto em português novamente. Essa frase é simples, mas muitas vezes as palavras demoram para se encaixar...e por isso faço várias traduções (em conjunto com o Babylon) até chegar a forma que considero a mais adequada.

O problema é que para fazer isso eu preciso manter duas janelas do browser abertas e ficar copiando e colando textos de uma para outra (claro, posso usar a combo de troca de linguagem, mas acho isso mais demorado que um Control-Tab).

Seria de grande valia, um botão como "Reverse translation", que pegaria o texto de resultado e faria uma tradução ao contrário, como:

Texto em português : Translate(portuguese to english) : Text in portuguese : Reverse translation : Texto em português.

Para mim seria uma "mão na roda", não sei para vocês. Mandei um feature request para o Altavista...quem sabe...

domingo, novembro 26, 2006

12.000 por mes, também quer?

R$12.000/mes. Trabalhar no México, com mais U$40 por dia de alimentação, hotel pago e uma passagem por mes pra passear em casa. Não tá ruim, né? Pois é, assim até eu fico com ciúme. Mas digo que fico com mais do que isso: eu fico indignado.
Indignado porque o cara que ganha isso não entende nada de EJB, nem XP, UML, RUP, CMM, anotações e nem tem idéia da existência de coisas como Hibernate, Ajax, Patterns, renderização, instrumentação de código, AOP, XUL e tantas outras coisas que arduamente a gente aprende. Em contrapartida, esse cara simplesmente entende (?) de três letrinhas básicas: SAP.
Sim, sem faculdade, sem inglês ou espanhol, sem noção alguma de gerência de projeto, arquitetura de sistemas e qualquer outra coisa, com 3 cursinhos e uma entrevista já levaram o cara daqui para essa que descrevi logo acima.
Não digo que tenho inveja, mas fico pensando porque a gente que conhece tantas outras coisas, que trabalha muito mais, tem muito mais experiência e uma visão muito maior da TI não consegue essas barbadas?
Eu, com 29 anos, com muito custo consigo uma alocação como projetista pra ganhar nem R$4.500. Luto contra o tempo para terminar o mestrado, dou cursos extras, faço consultoria, palestras e viro as madrugadas projetando e programando em projetos livres para não conseguir chegar nem na metade do que o cara ganha. Alguma coisa tá errada.
Por vezes penso em largar tudo que sei em várias áreas e descambar para esse lado de ERP. Fazer uns cursinhos (um pouco caros, é bem verdade) e ter um retorno "graúdo" a olhos vistos. Me desligo da sopa de letrinhas que domino, páro de ler livros, artigos, desisto dessa história de mestrado e doutorado e me foco em algumas provinhas e certificações e com um pouquinho de inglês e boa vontade, posso beirar os R$20.000.
Mas daí lembro que não gosto de viajar, não tenho muito paciência com essa história de lidar com usuários e, principalmente, minha visão autruísta das coisas me coloca de volta no lugar onde estou hoje: trabalhando sem retorno.
Quero ainda ganhar muita grana, mas quero - principalmente - a satisfação de saber que essa grana veio de coisas que eu criei, como o Merlin, o Magoo, o Jestor e agora, o recém-batizado Melvin. Como dizia um amigo meu, como satisfação de vida estaria o fato de termos montado uma empresa - a nossa empresa - e saber que o pão e o leite que o funcionário aquele leva para seus filhos em casa, foi resultado de uma idéia, um conceito, uma visão que tivemos muitos anos atrás. Uma idéia que teve de ser lapidada, trabalhada durante dias, noites, madrugadas, semanas, meses e talvez anos, mas que enfim, rendera seus frutos.
Sou assim, tenho um pontinho de ressentimento ao ver alguns colegas ganhado muito mais do que eu com muito menos esforço. Mas nem por isso me acrubunho e vou para o time deles. Luto, da minha forma, à minha maneira. Não desisto dos meus ideais e não mudo meu caminho. Por vezes, quem está comigo sofre junto, mas qual seriam os louros de uma vitória sem esforço?
Quando vejo o cara andando com seu 307 novinho, pareço ter uma recaída. Quando o vejo mais novo e com uma morena linda ao seu lado, meu estômago se revira. Mas ei que não largo da minha velha C10 e quanto à morena, não tem problema, pois em casa, mesmo longe, já tenho a minha amada, mãe de meu filho e eternamente apaixonada.
Continuo a trabalhar firme e confiante. Um dia, eu viro o jogo.

terça-feira, novembro 21, 2006

Campeonato de CVS


Tempos atrás (não lembro onde, acho que foi no JavaNET), tinha um ranking dos commits de CVS mais exóticos que o pessoal tinha feito nos projetos. Tinha muita coisa legal. Ganhou um cara que tinha feito um commit e no conteúdo desse ele acabava xingando a si mesmo por ter feito o commit. Muito estranho.
Bem, aqui na 3Layer muitas vezes os commits são feitos e a gente não sabe bem o que escrever. Porém, nesse que fiz acabei escrevendo algo que achei legal colocar aqui.
Perda de tempo, talvez, mas vale como histórico :-)

quinta-feira, novembro 16, 2006

Pisando no Google

Estava na aula quando me lembrei que o Bhertier estaria dando uma palestra tipo invite to Google no auditório verde da UFRGS. Quando sai da aula fui lá ver o que o cara tava falando. E gostei.
A visão do Google que objetiva a experiência do usuário como resultado final e o modelo horizontal de suas aplicações eram coisas que eu não tinha parado para pensar. Bem, quem vê a tela branca do Google e sua enorme eficácia de resultado (tanto na experiência visual quanto na experiência [quase que maravilhosamente] exata de seus resultados pode ter uma idéia. Mas não tem idéia de coisas como essas abaixo:

Deixa que eu chuto (ops, que eu monto!!!)
Você sabia que o Google é o quinto maior montador de computadores do mundo? Sim, o Google compra hardware de baixo nível (placas, HDs, etc.) e monta seus computadores (ou melhor dizendo, super clusters de computadores), incluindo até a escrita da BIOS, uma versão específica de linux e camadas (e mais camadas) de software para garantir disponibilidade, digamos, eterna. Sistemas de guarnição monitoram a si mesmos e avisam detalhadamente cada pequenino erro no gigantesto e distribuído computador virtual. Milhares de processadores distribuídos em vários de centros de processamento. O cara do suporte simplesmente recebe um avison no desktop: Ei panga, vai lá no slot 1542 do módulo 32 e troca o HD. O panga vai, tira o HD pifado (ou qualquer outro elemento que deu falha) e coloca outro. Pronto. O sistema automaticamente instala tudo de novo (até um SO novo no HD se precisar) e coloca ele pra bombear. Tudo hot deploy, claro. Minha dúvida sobre o acesso da 20 bilhões de páginas foi sanada. Um nodo central recebe a query do usuário e distribui ela para o cluster. Cada elemento do cluster possui uma parte dos índices para as páginas e processa a query. O cluster retorna as páginas obtidas da query e o nodo central funde os resultados e manda para o usuário. O nodo central opera em memória (e que memória) e os índices dos clusters possuem algoritmos próprios (ou seja, não existe nenhum SQL por trás - mas isso todo mundo já sabia, eu acho:-)

O início
Saber que tudo isso foi baseado numa idéia simples de convergência de grafos parece história da carochinha, mas foi isso mesmo. O projeto que rodava tranquilo no quarto do Larry e do Sergey na Universidade de Stanford, rapidamente esgotou a capacidade não só do prédio dos alunos, mas também do laboratório de informática da Universidade e logo mais o todo o link de Stanford. Resultado? Rua!!! Ou melhor, garagem para eles (parece que essa história de criar empresas de TI em garagem é vício). Olhando pelas fotos, me lembro bem do tempo que eu estava no prédio da JH Santos fazendo o projeto Mentor: comida no lado do teclado, algumas CPUs velhas no chão, olhos esbugalhados de noites em claro e muita esperança...ah, quem dera.

"O hoje"
Hoje o Google tem dezenas de serviços, centenas eu acho. Embora a maioria seja beta ou esteja no labs ou mesmo que a maioria das pessoas não conheça, podemos dizer que o Google é dono da informação. Informação preciosa essa, tal como a AOL descobriu quando decidiu liberar seus logs de acesso (...) Eu particularmente, sempre adorei o Google, desde que o Luis Fétido me mostrou aquela página branca pura "OOOOO" na parte de baixo.

"Pisando no Google"
Ah, antes que eu termine, de hoje em diante estou literalmente pisando no Google porque, sim, eu também ganhei um chinelão 43 deles.

segunda-feira, novembro 06, 2006

Programando aos pedaços

Antes de passar para vocês o que acho que será o futuro dos sistemas, vou retomar o assunto de ligar controles e eventos à regras de negócio que ainda não existem...
Todo mundo está acostumado a programar da seguinte maneira: dadas as regras de negócio definidas (pelo analista) e detalhadas (pelo projetista), essas são programadas (pelo programador) conforme as especificações contidas no processo de software (se existir, ahahaha). Isso significa que o programador vai construir a interface do usuário e ligá-la às regras de negócio através de pontos específicos: os eventos dos controles. Isso nada mais é que o modelo MVC, regra básica em aplicações desktop ou web.
A interface do usuário (IU) está sendo construída. Os eventos já estão definidos no pacote gráfico/controlador em uso (Swing, SWT, Strus, JSF, Ajax...) e são simplesmente estendidos ou utilizados. E as regras de negócio ou já estão prontas em componentes escaláveis (EJBs, Webservices, JMS, etc.) ou estão em classes simples mesmo. Ou se não estão, serão, assim como a IU, criadas on demand. Em outras palavras, tudo que você usa para criar o sistema ou precisa estar pronto naquele momentou ou você cria na hora. Isso é a programação tradicional. Todos fazem isso.
Mas já pensaram em programar a IU e ligar ela a uma regra de negócio que - seguramente - estará disponível somente daqui a 3 semanas?
Vou dar um exemplo simples: O programador está criando um cadastro para uma financeira e o projeto gráfico (as telas) está pronto, bem como o projeto navegacional. Como o programador é "bala", a tela está praticamente pronta. Falta, porém, o analista e o usuário decidirem se dentro da fórmula do imposto sobre operações do tipo XPTO (que ainda não se sabe se é esse o nome mesmo!!! - me desculpem os usuários e analistas) será feito usando a tabela de cálculo X ou Y ou se será uma "mescla" da fórmula existente no último sistema da casa (...)
O programador pergunta ao seu gerente: E aí, o que eu faço agora? Eu poderia colocar a tela em produção hoje, mas como ainda não tenho essa regra de negócio definida, não sei o que fazer. O gerente responde: Toca outra tela...quando eles se decidirem você termina isso [subentende-se aqui: volta daqui a 3 semanas; procura o TODO que você colocou no código-fonte (colocou mesmo?); modifica os comandos navegacionais do controlador (vários XMLs) que faziam a página A ir para a C diretamente - sim, porque agora que a página B com o cálculo do financeiro está pronta e o esquema o fluxo do sistema muda de novo, testa, empacota redeploya e, ufa, vai tomar um cafezinho).
Minha pergunta é: Não seria mais interessante o programador ter feito algo como:

Agent.bind("btnCalcular", "click", "calcularImpostoSobreOperacoesXPTO")

E colocar a aplicação em funcionamento 3 semanas antes sem se preocupar como a regra do imposto será implementada? Simplesmente quanto ela estivesse pronta, a aplicação detectaria isso e ligaria o botão, o evento e a regra transparentemente.
É justamente isso que acontece quando o Merlin é usado para fazer o binding de regras denegócio: não importa se a regra está progamada ou não, o binding é feito e quando a regra estiver disponível a coisa simplesmente acontece.
Extrapolando esse conceito, fábricas de software poderiam criar sistemas de forma totalmente fragmentada, colocando-os em funcionamento mesmo que seus "pedaços" não estivessem disponíveis ainda.
Essa proposta não é nova para mim. Na verdade, o projeto Jestor, data de mais de 3 anos e é uma coisa que ainda quero desenvolver.
Obviamente, o exemplo que dei é uma minimização do assunto, pois aspectos diversos, como segurança, contexto de execução e outros estão envolvidos. Mas o importante é dizer que o Merlin já suporta a ligação de regras de negócio mesmo se elas ainda não estiverem disponíveis.
Se tudo correr bem, depois do Merlin, do Magoo e do projeto X (desculpem, ainda não tenho nome ainda para o gerador de relatórios que vai usar as bases do Merlin para renderizar os famigerados reports dos sistemas), o Jestor será a chave para fechar a arquitetura que tenho em mente.
Claro, devem correr mais uns 5 anos ainda, mas quando o Dolphin já for a JRE padrão nos sistemas operacionais, o Jestor bem que poderia ser um pacote estável pronto para download em algum repositório público como o SourceForge ou JavaNet.