Máquinas Criando Máquinas

Tá bom, eu sei que o exemplo que utilizei no artigo sobre o paradigma das aplicações corporativas, para ilustrar o conceito de orientação ao aspecto foi muito ruim.

A idéia do lenço e da lama não é exemplo digno de apresentar a inversão de controle.

Eu vou voltar nesse assunto no próximo artigo, mas agora gostaria de escrever sobre a automatização na criação de software.

Descobri recentemente um programa chamado MyGeneration. Muitos devem conhecer, mas eu mesmo só comecei a utilizá-lo há pouco tempo.

Esta fantástica ferramenta se propõem a expôr objetos do banco de dados de uma forma que fica fácil e intuitivo criar pequenas aplicações para geração de códigos repetitivos, em lote.

A idéia é construir todo o modelo da aplicação em uma ferramenta específica, como o Enterprise Architect, e por fim montar o banco de dados.

Ou seja, na modelagem, o arquiteto deve desenhar as entidades do domínio baseadas nos requisitos e nas funcionalidades propostas. E seguindo as propostas da UML, o arquiteto então deve continuar a trabalhar no modelo, criando os diversos tipos de diagramas, orientado pela metodologia, até chegar no desenho do banco de dados.

Nesse ponto é onde o MyGeneration entra para montar o esqueleto da aplicação. Eu construí um conjunto de scripts para geração automática de código, que sozinho constrói todas as camadas de aplicação com apenas alguns cliques. Um dos scripts cria automaticamente até classes de teste unitário para ajudar a manter a integridade do sistema.

Com esses scripts eu consigo colocar uma aplicação com mais de cinquenta casos de uso no ar e funcionando, em questão de duas horas.

O segredo do MyGeneration é expor todos os objetos de um banco de dados em forma de coleções, facilmente programáveis.

Imagine ter acesso a todos os nomes de tabelas do banco de dados, os campos, as chaves estrangeiras, as chaves primárias etc?

Apenas com essas informações já ficaria muito fácil construir um laço para "rodar" todas as tabelas do banco, e montar os códigos necessários para a implementação das classes de entidades e dos arquivos de configuração do Hibernate.

Além disso, o MyGeneration oferece todas as funcionalidades do C# e do Framework .Net. A programação flui fácil por causa disso. Não só do C#, mas do Visual Basic também.

Além de tudo isso é grátis!

Mas, como sempre tem um "mas"... a interface do programa é muito fraca ainda. Está amadurecendo, mas ainda engatinhando.

O intellisense mal funciona e as cores são terríveis. Faltam vários auxílios de digitação e de identação do código.

Resumindo, a idéia é ótima! Mas a aplicação deixa a desejar. Acho que a equipe de desenvolvimento desse software pecou apenas na abordagem do framework deles.

Acredito que eles não deveriam ter construído uma IDE (Integrated Development Enviroment) para abrigar este interessante framework de escavação de objetos do banco de dados.

Eu teria feito diferente, eu teria criado uma DLL para ser utilizada como wrapper em projetos dentro do Visual Studio. Essa DLL poderia ter um template de criação de projeto (aqueles projetos que aparecem na caixa de "Criar Novo Projeto...") e referenciar automaticamente essa DLL de wrapper.

Algumas configurações no web.config ou no app.config seriam suficientes para carregar automaticamente o contexto do framework de escavação de dados, e o acesso aos objetos do banco estariam disponíveis dentro do Visual Studio.

Ou seja, o que quero dizer é que não é necessário criar uma IDE nova, basta aproveitar a melhor IDE que existe, que é o Visual Studio e instalar o framework como opcional.

Dessa forma o desenvolvedor poderia fazer o mesmo trabalho que faz no MyGeneration, mas dentro do Visual Studio, com todo suporte de intellisense, coloração de palavras-chave, auto identação, debug etc.

Não estou com tempo para desenvolver essa ferramenta agora, mas vou pensar seriamente nisso.

Até a próxima!
[]s
Renato Graccula

Padrões de Desenvolvimento

Paradigmas e mais paradigmas. Os padrões de desenvolvimento estão na moda. Façade, Abstract Factory, MVC, Gang of Four etc etc.

Mas onde vai parar tudo isso? Como podemos pensar em um padrão de desenvolvimento em camadas se nem sequer conseguimos decidir o padrão para os nomes dos campos das tabelas ou mesmo das variáveis?

Eu digo que o buraco é mais embaixo. Um pouco de história deve ajudar.

Esse modelo de desenvolvimento vem do Java. Nada disso é novo para os programadores e arquitetos especializados em Java.

Os programadores Microsoft estão experimentando isso pela primeira vez. Natural virar moda, afinal de contas finalmente essas disciplinas saíram do baú, ou seja, saíram daquelas panelinhas de profissionais que apenas eles conseguem devorar tanta informação e digitar tanto código em tão pouco tempo.

Resumidamente, essas tecnologias saíram das faculdades de gênios e intelectuais e caíram na mão do povo! Dê ao povo o que é do povo!

Agora nós mortais temos acesso a essas novas (velhas) formas de arquitetar e programar software.

Isso na verdade aconteceu pois a Microsoft enveredou por um caminho de Orientação a Eventos como o Visual Basic enquanto o Java rumava para a Orientação ao Objeto. E diga-se de passagem o Java venceu a batalha. Mas a Microsoft deu a volta por cima e fez o que ela sabe fazer melhor: copiou tudo do Java e criou uma tecnologia fantástica chamada .Net!

A Microsoft foi além, criou o C# para dar um xeque-mate no assunto. Pronto, nem precisa dizer qual tecnologia eu prefiro e que será assunto dos meus posts nesse blog.

Passada essa etapa, voltemos ao problema dos padrões de campos de tabela e variáveis.

Resolvi tocar nesse assunto para dissertar sobre um problema que estou vivenciando. Atualmente estou fazendo o papel de programador em uma equipe de desenvolvimento. Equipe esta que conta também com mais um programador e um arquiteto.

Até aí tudo normal. O interessante da história é que o arquiteto veio do mundo Java. Não preciso falar mais nada depois de ter escrevido esses eloquentes parágrafos anteriores.

Mas nós estamos nos dando bem e não tenho nada contra o mundo Java, apenas não o conheço. Esse é o único motivo da minha aversão.

O objetivo desse post é falar sobre um assunto em especial. Nomenclatura de campos e variáveis. É um ponto onde o arquiteto e eu discordamos.

Ele criou um padrão de nomenclatura dos campos utilizando um acrônimo para o nome da tabela, seguido de um underline e depois o tipo do campo abreviado e finalmente o nome do campo.

Então se temos um campo Nome do tipo varchar na tabela Usuario, o nome do campo fica assim: USU_ChaNome.

O conceito é interessante, pois temos todas as informações do modelo no nome do campo.

Fico me perguntando porque isso seria necessário? Porque o campo Nome da tabela Usuário precisa ter conhecimento de todo o modelo?

Esse conceito pode ser interessante quando utilizando na programação espagueti, onde existe tanto código embarcado que o nome do campo precisa trazer junto uma série de informações adicionais para lembrarmos o que estávamos fazendo. Para que não precisemos procurar essas informações em outras camadas, pois é tanto código escrito, que demoraria muito.

No .Net isso não funciona. Os frameworks estão encapsulando todos os códigos adicionais e fica muito fácil achar as coisas nas poucas linhas de código que escrevemos.

Isso sem falar no fato de que para o progrador é muito mais fácil de pensar no modelo de cima para baixo e não de baixo para cima, como é o ponto de vista do arquiteto.

Então na hora de programar é muito mais fácil escrever Usuario.Nome do que Usuario.USU_ChaNome.

Seguindo a linha de raciocínio do programador, quando este precisa de uma informação ele primeiro precisa pensar na classe do modelo. Se ele já pensou isso, porque ele precisa pensar de novo na classe do modelo ao escrever o nome do campo? E ainda mais, lembrar o tipo do campo. Só então escrever o nome do campo. Nessa hora o programador já até esqueceu qual era o campo mesmo?

Talvez isso seja herança remanescente do modelo relacional de pensar. O banco de dados deve ser abstraído para o modelo orientado ao objeto. E essas heranças da época do código espagueti precisam morrer, assim como esses políticos brasileiros. O tempo deles acabou, agora é a era dos mais jovens.

Até a próxima!
Renato Graccula

Paradigmas das Aplicações Corporativas

Fui apresentado a esse termo recentemente. Lógico que já ouvi falar em aplicação corporativa, mas agora estou comprometido a desenvolver um sistema desses.

A empresa onde estou trabalhando montou uma equipe para ter uma área pioneira em desenvolvimento de sistemas corporativos.

Meu mundo caiu e estou acordando em outro, completamente diferente. O foco mudou.

Antes, no meu ponto de vista, o desenvolvedor sentava com o cliente, ouvia suas necessidades e montava o programa conforme o entendimento do problema.

Ainda nesse cenário, o programador não tinha códigos prontos e nenhuma facilidade. O próprio desenvolvedor analisava as necessidades do cliente, montava a estrutura do programa e ainda codificava e testava a aplicação.

Esse cenário mudou. Hoje em dia, o desenvolvedor recebe do arquiteto a aplicação pré-montada. Em rápidas reuniões técnicas sobre problemas específicos, o arquiteto e o desenvolvedor alinham o entendimento geral do projeto e seguem em frente.

Nesse novo cenário, o cliente nem sabe da existência do programador. E este ainda conta com muitas facilidades, como frameworks específicos para abstrair partes complicadas de se fazer na mão. Resumindo, o programador hoje em dia tem muitos blocos de código prontos para utilizar em sua programação, facilitando assim o que chamamos de "trabalho sujo" ou ainda "trabalho pesado".

Um exemplo disso é o NHibernate. Este framework se propõem a montar todas as querys SQL para você, independente do banco de dados que você utiliza, seja ele Sql Server, Oracle, MySql etc.

Isso facilita muito as coisas, pois basta mapear as tabelas do banco em um formato específico do NHibernate e criar classes que representam as tabelas dentro da aplicação, e o framework cuida do resto.

Mas não pára por aqui. Existem ainda programas como o MyGeneration que auxiliam na criação de códigos repetitivos. Através de templates programados pelo próprio desenvolvedor, ou mesmo baixados da internet, podemos criar arquivos de mapeamento e classes inteiras com apenas alguns cliques.

Resumindo mais uma vez, hoje em dia basta você ter bons templates para implementação de código repetitivo, alguns frameworks para fazer o trabalho sujo e voilá: você pode se tornar um ótimo programador!

Veja que com essa mudança na forma de programar, mudou também o foco da aplicação. A programação não é mais voltada para o objeto, para o método ou mesmo para o evento. Agora é voltada para o aspecto da aplicação, ou para o serviço a ser prestado, para o domínio do negócio, ou ainda para os testes de sistema.

Isso mesmo, o objeto não é mais o foco do problema. Foi natural durante um tempo que a programação orientada a objetos permanecesse como motivo de preocupação. É realmente difícil aprender orientação a objetos. A curva de aprendizado no início é muito íngreme. Leva-se muito tempo para começar a desenvolver alguma coisa até pegar o jeito.

Mas o tempo foi passando e os desenvolvedores foram ficando habituados a esse tipo de programação. Isso fez com que o foco mudasse, ou seja a preocupação mudasse. Já que não era mais segredo desenvolver aplicações orientadas ao objeto, qual era a preocupação então?

Isolar os objetos em contâiners. Imagine que você tem um objeto muito valioso e delicado. Por exemplo um lenço para limpar os olhos. Se este lenço cair em uma poça de lama, como você vai separar a lama do lenço de forma que ele fique novamente apto para limpar seus olhos?

Esse é o problema com os objetos. Muitos deles estão tão acoplados e tão dependentes uns dos outros que não podem ser separados e reaproveitados em outros projetos. De repente esses objetos não ficam mais tão atraentes. Para que serve um objeto se eu não posso utilizá-lo mais de uma vez, em outros programas?

É a mesma coisa com o lenço. Mas qual a solução? Bom, para o lenço, o ideal seria que você pudesse colocar a maior parte do lenço dentro de um invólucro e selá-lo, deixando apenas uma ponta do lenço para fora. Dessa forma apenas essa parte do lenço ficaria exposta para se acoplar com a lama. Você então teria cumprido seu objetivo de sujar o lenço de lama sem estragá-lo de vez, pois boa parte do lenço ainda está limpa.

Seguindo essa mesma idéia do lenço, os objetos gerados pelos programadores também devem ser encapsulados e isolados. Assim bastaria acoplar conectores cabíveis para cada aplicação que necessitasse deste objeto. Temos então um objeto reutilizável!

Com essa idéia em mente as grandes empresas descobriram ser um grande negócio agrupar estes objetos com propósitos em comum, em grandes pacotes chamados de frameworks. Esses pacotes são aplicações inteiras com o único propósito de servir de plataforma para o desenvolvimento da sua aplicação.

Na verdade tudo isso que estou escrevendo define a quebra do paradigma relatada pelo pattern Separation of Concerns (Separação de Preocupações). Ultrapassada essa etapa, podemos dar atenção a outros problemas, como partes do sistema que transcendem as camadas e os objetos.

Um exemplo disso é o Log (rastro), pois um sistema de rastreamento ultrapassa as camadas da aplicação e dos objetos. Se não tomarmos cuidado, esse Log pode ficar tão acoplado com as classes a ponto de torná-las totalmente dependentes e incapazes de funcionar sozinhas em outros sistemas.

Chegamos então a outro paradigma: Inversão de Controle!

Aguardem novos capítulos!
Renato Graccula

Triste Brasil

Eu estou triste. Vou postar um artigo técnico ainda hoje, mas agora estou precisando reclamar de algumas coisas.

Brasil. Pátria amada... Está tão difícil amar esse país ultimamente. Os bandidos estão dominando o país. Tem bandido, ladrão, estelionatário por todo o lado. Não olhe!

Agora não podemos mais nem nos divertir. Na verdade, quando pudemos? Nossos filhos não podem mais brincar na rua. Até para ir a escola tem que ser em carro blindado.

Qual a solução? Ir para o interior. Fugir da capital. Ares mais puros, pessoas mais simples e... ladrões. Por todo lado. Piores que os da cidade. Pois na cidade ainda existe alguma ordem e lei. Acredite, perto do que está acontecendo nos arredores de São Paulo, a capital é até uma cidade civilizada.

Eu gosto muito de pilotar minha moto pelas encostas da serra da Cantareira, em Mairiporã. Lugar lindo, cheio de cachoeiras, represas, lagos, morros, pedreiras etc. Lugar bom para praticar motocross, rapel, ciclismo etc. Lá temos parques onde se pode andar a cavalo, deslizar em uma tiroleza, ou simplesmente comer uma bela feijoada ou uma pizza aperitivo.

O fato é que não podemos mais aproveitar tudo isso. O lugar está servindo de palco para uma gangue de ladrões de moto. Sabe qual o pior? As pessoas sabem quem são os ladrões e ninguém faz nada.

A Serra da Cantareira já estava sendo atacada há um bom tempo por uma outra gangue. Dois anos atrás roubaram a moto de um amigo meu. De lá para cá, nós mudamos nossa rota para não chegar perto da área onde os bandidos estavam agindo. Mas como a impunidade reina, os ladrões não se sentiram nem um pouco incomodados em chegar mais perto.

Neste final de semana fomos pilotar nas trilhas de Mairiporã. Inclusive o meu amigo, Alemão, que teve sua moto roubada dois anos atrás foi comigo.

Para começar, erramos o caminho. Demos uma volta e atrasamos a chegar no Pedrão, um bar tradicional que é o ponto de partida para as trilhas. Estacionamos o carro, desmontamos as motos, vestimos o equipamento e saímos para pilotar.

Já no primeiro trecho a moto do Alemão apagou completamente no meio de uma subida de pedras. Não tinha como descer nem subir. Tivemos que desmontar a moto dele ali mesmo. Tivemos que tirar tudo: laterais, banco, tanque e até o filtro de ar. No final descobrimos que era o conector do relê de partida. Coloquei um famoso "enforca-gato" para segurar o conector no lugar, montamos tudo e continuamos. Uma grande perda de tempo, pensamos. Atrasou o percurso em mais de uma hora!

Na verdade, a moto do Alemão parou de novo e na segunda vez que eu coloquei o enforca-gato. Perdemos mais que uma hora.

Terminando a primeira parte da trilha, que inclui a volta para o Pedrão, a moto do Alemão pifou de novo. Dessa vez travou a roda traseira. As pastilhas do freio a disco travaram fechadas e não havia como destravá-las. A solução foi abrir o respiro. Pra quê? Na mesma hora que abri o respiro, jorrou fluído fervendo. Parecia uma chaleira!

Resultado: fluído de freio acabou e o bendito do Alemão teve que pilotar sem freio. Voltamos pelas estradas de terra até o Pedrão. Lá sentamos para tomar uma cerveja, enquanto o Alemão e o Márcio iam comprar fluído. Quando eles voltaram, preparamos tudo de novo e saímos para fazer a segunda etapa.

Saímos do Pedrão, pegamos a Estrada das Roseiras com cuidado para não dar de cara com um comando da polícia florestal e subimos a estrada de terra que passa pelo alambique do Belarmino.

Antes mesmo de chegar ao Belarmino, cruzamos com duas motos de trilha. O primeiro, pilotando sozinho, o segundo com garupa. Só que eles estavam de cueca!

Fizeram sinal. Imediatamente fizemos a volta e seguimos eles até o Pedrão. Lá começamos a conversar. Disseram que foram assaltados logo depois da manilha, que é uma trilha não muito longe e que nós fatalmente passaríamos por ali!

Os bandidos saíram do mato, munidos de pistolas calibre .38. Levaram quatro motos e muitos equipamentos. Esses ladrões não apenas roubaram, como escolheram as motos que iriam levar. Chegaram a parar acredito que uma meia dúzia de trilheiros. Escolheram as quatro melhores motos e levaram.

Fomos conversar então com o dono do Pedrão. Nós fazemos trilha lá há mais de quatro anos. Conhecemos bem nosso anfitrião. Quando contamos o que aconteceu ele ficou transtornado! Disse que do jeito que estava indo ele ficaria sem o negócio dele, pois cada vez menos trilheiros estão visitando a região, com medo dos assaltos.

Conversando com mais outras pessoas descobrimos coisas mais atordoantes ainda. Todo mundo sabe quais são os integrantes da gangue e onde eles ficam. Só que o problema é que ninguém tem coragem de fazer nada e a polícia não tem "interesse" em resolver o problema.

O pior é que para resolver a situação é só pagar para a própria polícia, quatro mil reais por indivíduo a ser "apagado". Estamos falando de doze mil reais para acabar com a tal gangue. Mas existe uma solução mais barata que é contratar um outro bandido, que cobra mais barato que a polícia, claro, para resolver a situação por um pacote exclusivo por mil e quinhentos reais.

É senhores e senhoras. Esse é o país onde vivemos. E aí, acharam mais fácil ou mais difícil amar esse país depois dessa?

Fui.
Renato Graccula