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
sábado, 21 de março de 2009
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.
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:
O que eu fiz, foi colocar a seguinte instrução dentro de um arquivo .BAT:
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:
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:
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:
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
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 na imagem para ampliar.
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 BINRepare 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 objPerceba 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 na imagem para ampliar.
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.
É 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.
Assinar:
Postagens (Atom)