sábado, 21 de março de 2009

Mudança de Endereço

Pessoal,

Comecei a publicar em outro blog. O problema do blogspot é que é bloqueado na empresa onde trabalho, mas este novo endereço não é:

http://graccula.spaces.live.com/

Ah! E quem quiser acessar do iPhone, o endereço é:

http://graccula.mobile.spaces.live.com/

Abraços,
Renato

sexta-feira, 6 de março de 2009

Profiler Para SQL Server 2005 Express

Sentiu falta do Profiler do SQL Server 2005, versão Express?

Eu também. Faz uma falta, principalmente quando se utiliza um framework de mapeamento Objeto Relacional (OR), como o NHibernate.

Como o framework faz todo o trabalho de montar o script de execução do banco de dados, quando algum problema ocorre, um Profiler ajuda muito, principalmente para saber o que realmente o NHibernate está montando.

Encontrei um Profiler freeware desenvolvido por uma equipe chamada AnjLab. O software não é nenhuma maravilha em termos de opções, mas é de graça e cumpre a função com destreza.

Baixe o AnjLab SQLProfiler no link abaixo:

http://anjlab.com/en/projects/opensource/sqlprofiler

O software é super simples de configurar e tem as opções básicas logo de cara. Basta configurar os eventos a serem monitorados e os filtros e tudo pronto.

Este Profiler peca apenas na apresentação do LOG, pois é impossível alterar as colunas e a visualização fica prejudicada por isso. Não sei se alguma versão nova foi lançada, mas se foi, a que testei tem essas características.

Até a próxima,
Graccs.

quarta-feira, 4 de março de 2009

Truque Para SubVersion

Pessoal, estou colocando esse post no blog, pois durante muito tempo pesquisei uma forma rápida e fácil de apagar diretórios dentro de diretórios.

Quem utiliza o SubVersion sabe que isso é muito útil de vez em quando. Por duas razões: a primeira é que sempre que compilamos uma aplicação .Net, o Visual Studio cria dois diretórios dentro de cada projeto: bin e obj; a segunda razão é quando queremos retirar um projeto do controle do SubVersion e precisamos apagar o diretório .svn dentro de cada diretório da aplicação.

Essa tarefa é muito enfadonha, principalmente quando a aplicação possui dezenas de pastas.

O problema com os diretórios bin e obj é que eles contém diversos arquivos resultantes da compilação, inclusive vários sub-diretórios temporários. E não queremos estes diretórios dentro do repositório, pois são produtos da aplicação e não código-fonte.

A receita que eu achei é bem simples, mas também bem curiosa. Eu por exemplo não sabia que o DOS tinha um comando de laço FOR. Pois é, esse comando existe e funciona muito bem!

Digitando FOR /? na linha de comando do DOS, podemos ver um texto que nos auxilia a montar o comando. Por exemplo:

Clique para ampliar.
Clique na imagem para ampliar.

Veja que dessa forma, podemos executar um comando dentro de um laço de arquivos.
O que eu fiz, foi colocar a seguinte instrução dentro de um arquivo .BAT:

FOR /F "tokens=*" %%G IN ('DIR /B /AD /S *%1*') DO RMDIR /S /Q "%%G"

Este comando acima executa o comando DIR com as opções de pesquisa por diretório e com recursividade, para entrar em todos as sub-pastas.

O comando RMDIR remove cada pasta encontrada que atende o filtro *%1*. O parâmetro %1 é informado pela linha de comando. Se chamarmos o arquivo de lote de DELSUBDIR.BAT e quisermos apagar as pastas BIN, então teremos a seguinte instrução:

DELSUBDIR.BAT BIN

Repare que este comando acima utilizará o seguinte filtro: *BIN*. Ou seja, apagará todos os diretórios que tiverem o termo BIN no nome, seja no começo, meio ou fim. Tome cuidado então caso na sua aplicação você tenha um diretório chamado: "Albino", por exemplo. Por isso, ajuste o comando para suas necessidades.

Bom, para facilitar o trabalho, eu criei um outro arquivo .BAT para apagar as pastas BIN e OBJ recursivamente e o incluí no diretório SendTo (EnviarPara) do Windows.

Eu criei então o arquivo DEL_OBJ_BIN.BAT com as seguintes instruções:

@echo off
cd %1
call delsubdir bin
call delsubdir obj


Perceba que o comando CD %1 é importante para alterar o prompt da linha de comando para o diretório que terá os BINs e OBJs apagados.

Mais uma vez o %1 é um parametro de linha de comando, passado para o arquivo .BAT na execução.

Mas dessa vez, como vamos colocar esse arquivo dentro da pasta SendTo, esse parâmetro será automaticamente passado para o arquivo .BAT quando selecionarmos o menu de contexto apropriado. Veja exemplo abaixo:


Clique para ampliar.
Clique na imagem para ampliar.

Pronto, é isso! Simples assim, basta clicar com o botão direito no diretório e selecionar Enviar para -> Del_Bin_Obj.bat e todos os diretórios BINs e OBJs somem instantaneamente!

Lembre-se que apesar de aparecer no menu de contexto a opção "Enviar para", o diretório chama-se SendTo e fica em:

C:\Documents and Settings\[Nome do Seu Usuário Logado]\SendTo

Até a próxima!
Graccs.

terça-feira, 3 de março de 2009

Desacoplamento

Vamos falar um pouco desse assunto.

É um assunto bem interessante e gerou uma baita confusão hoje lá no escritório. Não vou entrar em detalhes sobre a confusão causada pois envolve questões políticas e comerciais que não tenho o menor interesse e acho que não cabe nesse blog.

Mas o interessante dessa questão é justamente a confusão que gera. O que é desacoplamento? Eu entendo como um tipo de isolamento entre camadas ou aspectos diferentes.

Por exemplo, quando instanciamos um objeto para utilizar seus métodos e propriedades, estamos criando uma dependência para aquele objeto. Se ele por algum motivo este objeto não estiver presente no momento do desenvolvimento, o programa que depende deste objeto sequer compilará.

Isso em um ambiente de desenvolvimento isolado não causa muitos problemas, pois normalmente todos objetos estão a disposição do desenvolvedor, ou ainda este os está criando, então essa equipe tem controle total sobre as dependências do projeto.

Mas em um outro cenário, como o que estou vivenciando na empresa onde trabalho, temos uma outra situação. Duas equipes de empresas diferentes estão trabalhando em um mesmo projeto.

Não pense que ao ler este blog você encontrará todas as respostas. Na verdade, eu não tenho essas respostas, pois ainda estou fazendo as perguntas. A experiência nos está guiando para um rumo que não está dando certo, portanto, é a melhor forma de se obter as respostas.

Quando as coisas vão bem, não sabemos se está dando certo por um ou por outro motivo, não importa. Mas quando as coisas dão errado, procuramos de forma mais objetiva resolver esses problemas e com isso vamos achando as soluções. E dessa forma temos certeza que são as respostas certas, pois as perguntas começam a surgir; e essas sim importam!

O que acontece é que a outra equipe está desenvolvendo a camada de interface, no caso, Web. Nós estamos desenvolvendo a camada de serviços.

A confusão começou pela decisão de passar a fórmula para desenvolver a camada de serviços para a outra equipe, que não entendeu nem para que serve essa camada.

Ou seja, nós estamos desenvolvendo essa camada de serviços e a outra equipe também. Depois a idéia era juntar os pedaços. Aproveitaríamos a camada Web desenvolvida pela outra equipe, e a camada de serviços deles seria descartada e a nossa utilizada no lugar.

Isso gerou uma baita confusão, pois a outra equipe desenvolveu a camada de serviços de forma errada e agora nos acusa de ter gerado muito acoplamento.

Surgiu então a dúvida, como desacoplar o desenvolvimento das duas equipes? Eis a pergunta que realmente importa!

Existem alguns níveis de desacoplamento. Um deles é gerar interfaces, em forma de contrato de todas as classes que compõem a camada de serviços. Depois passar essas interfaces em uma DLL separada para a outra equipe e eles saberiam exatamente como acessar os métodos necessários para o desenvolvimento.

Mas este nível de desacoplamento não seria suficiente, uma vez que apenas as interfaces, sem implementação não são suficientes para os desenvolvedores da outra equipe sequer compilarem os seus códigos. Pois a única coisa que eles poderiam fazer seria tipar os objetos. Mas não instanciá-los. Toda e qualquer instância depende da classe concreta.

A solução seria então adotar um framework específico para isso baseado no padrão de injeção de dependência e inversão de controle. Ou seja, os objetos seriam injetados de forma declarativa (leia-se configurações em arquivos XML) para não gerarem dependência no ato da compilação. Invertendo-se assim o controle de quem precisa do quê.

Agora nesse exato momento, estou ponderando onde erramos, pois a abordagem utilizada foi exatamente a explicada no parágrafo anterior. Para isso, o arquiteto decidiu utilizar o framework Spring.Net.

Aparentemente todos os problemas pareciam estar resolvidos, mas não. Acredito que nosso erro foi exatamente em passar a receita para esse modelo de desenvolvimento para a outra equipe, que no final das contas se deparou com dois problemas, e não apenas um, como eles esperavam.

O que quero dizer é que eles além de aplicar a injeção de dependência, tiveram que estudar e implementar a programação dos serviços. E isso não é tarefa fácil.

Acredito que deveríamos ter passado para eles apenas as nossas interfaces, e os orientado a apenas injetar as implementações. E não a ter que implementar também o que seria injetado, pois essa deveria ser nossa responsabilidade.

O resultado é que gerou tensão entre as duas equipes e ainda o resultado final do produto que eles criaram ficou confuso e ruim. Sem falar que ficou muito diferente do nosso.

Como a camada de serviços da outra equipe ficou diferente da nossa, não pudemos então apenas substituir a programação deles pela nossa. Essa era a idéia original, que foi pelo buraco.

O que se segue é que amanhã a equipe de fora vai para dentro, trabalhar ao nosso lado, para que possamos sincronizar os códigos e atingir o objetivo.

Frustrante.

Até a próxima,
Graccs.

quarta-feira, 18 de fevereiro de 2009

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

sábado, 14 de fevereiro de 2009

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

quarta-feira, 4 de fevereiro de 2009

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