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.
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
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
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
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
terça-feira, 3 de fevereiro de 2009
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
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
sexta-feira, 30 de janeiro de 2009
Falta de Permissão na Instalação do .Net 3.5
Resolvi escrever esse post por causa de um problema que tive na instalação do Framework .Net 3.5.
Para falar a verdade é um problema específico que acontece por falta de permissão do usuário que efetua a instalação, mas como esse cenário é comum nas empresas hoje em dia, tenho certeze que vai servir para alguém.
Para detalhar o problema, preciso explicar como funciona a rede na empresa onde trabalho. Lá os computadores ficam em baixo do piso. Os desenvolvedores não têm acesso físico à máquina. Não podemos nem desligar as benditas! Eu fiz isso no primeiro dia. No dia seguinte, tiveram que chamar o técnico. Que vergonha, o sujeito teve que levantar o piso e colocar metade do corpo dentro do chão para religar a máquina. Uma cena bizarra!
Bom, a rede não poderia ser diferente. Tudo é controlado de forma rígida. Tive que assinar dois documentos: um para autorizar a criação do meu usuário na rede; outro para justificar o motivo de meu usuário necessitar privilégios de administrador do computador.
Apesar de tudo isso, não tenho controle total sobre meu computador. Existem algumas normas configuradas no Active Directory (AD) que me impedem de acessar recursos como: adicionar e remover programas, papel de parede do desktop, entre outras configurações do Windows.
Para verificar se o Service Pack 2 (SP2) do Framework .Net 2.0 estava instalado, eu precisei criar um usuário no meu computador, com privilégios de administrador, sair da sessão (logoff) e entrar com esse usuário local. Só dessa forma consegui acessar a opção adicionar e remover programas do Windows.
Tendo esse cenário em vista, começam os problemas. Eu precisava instalar o Visual Studio 2008! E logo na primeira etapa, que é justamente a instalação do Framework .Net 3.5, o instalador abortava e saía da instalação com erro. Tentei primeiro diversas coisas como: reiniciar o computador, limpar o registro, logar com um usuário local, fora da rede etc.
Comecei a descobrir a solução quando baixei um pacote de instalação do .Net 3.5 separado da instalação do Visual Studio.
Download do pacote completo de redistribuição do Framework .Net 3.5
http://download.microsoft.com/download/6/0/f/60fc5854-3cb8-4892-b6db-bd4f42510f28/dotnetfx35.exe
Pelo log do instalador, eu vi que o problema era em um componente chamado XPSEPSC que estava causando o erro. Eu descobri um link para baixar e instalar separadamente o tal componente problemático.
Instalador do XPSEPSC
http://www.download.windowsupdate.com/msdownload/update/v3-19990518/cabpool/xpsepsc-x86-en-us_f01c40d4ce7a451a51724bb2c44c164d063938e6.exe
Nesse momento eu vi uma mensagem de erro na instalação do XPSEPSC que me chamou a atenção. Alguma coisa dizendo que eu precisava de priviégios administrativos para continuar na instalação. Percebi então que o problema era de segurança e alguma norma do AD estava interferindo em minha instalação.
Nas pesquisas que fiz, descobri que este problema também se apresenta na forma de uma mensagem de erro que informa um termo "return value 3".
Para resolver, encontrei um pacote de ferramentas para administração e manutenção de servidores de forma remota. Chama PSTools. Nesse pacote tem uma ferramenta sensacional chamada PSExec.exe. Essa ferramenta faz uma impersonalização - se é que essa palavra existe - mas basicamente ela executa uma outra aplicação "por você" com identidade do usuário System, que é o usuário local com permissão total no Windows.
Instalador do PSTools
http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx
O PSTools é um pacote de aplicativos, e o que nos interessa é o PSExec. Copie-o no diretório do Windows para ficar mais fácil de usar, pois ele é utilizado via linha de comando.
Utilize o comando abaixo para executar o instalador do XPSEPSC, por exemplo:
psexec -s -i "c:\exemplo\XPSEPSC-x86-en-US.exe"
Sempre digite o caminho absoluto. O PSExec não funciona com paths relativos.
Outro detalhe. Não se assuste se o seu anti-virus detectar esse aplicativo como um vírus. O próprio autor comenta no site do link acima que esse programa já foi usado por vários vírus para efetuar suas ações maliciosas, mas ele em si não é um vírus.
Até a próxima!
Renato Graccula
Para falar a verdade é um problema específico que acontece por falta de permissão do usuário que efetua a instalação, mas como esse cenário é comum nas empresas hoje em dia, tenho certeze que vai servir para alguém.
Para detalhar o problema, preciso explicar como funciona a rede na empresa onde trabalho. Lá os computadores ficam em baixo do piso. Os desenvolvedores não têm acesso físico à máquina. Não podemos nem desligar as benditas! Eu fiz isso no primeiro dia. No dia seguinte, tiveram que chamar o técnico. Que vergonha, o sujeito teve que levantar o piso e colocar metade do corpo dentro do chão para religar a máquina. Uma cena bizarra!
Bom, a rede não poderia ser diferente. Tudo é controlado de forma rígida. Tive que assinar dois documentos: um para autorizar a criação do meu usuário na rede; outro para justificar o motivo de meu usuário necessitar privilégios de administrador do computador.
Apesar de tudo isso, não tenho controle total sobre meu computador. Existem algumas normas configuradas no Active Directory (AD) que me impedem de acessar recursos como: adicionar e remover programas, papel de parede do desktop, entre outras configurações do Windows.
Para verificar se o Service Pack 2 (SP2) do Framework .Net 2.0 estava instalado, eu precisei criar um usuário no meu computador, com privilégios de administrador, sair da sessão (logoff) e entrar com esse usuário local. Só dessa forma consegui acessar a opção adicionar e remover programas do Windows.
Tendo esse cenário em vista, começam os problemas. Eu precisava instalar o Visual Studio 2008! E logo na primeira etapa, que é justamente a instalação do Framework .Net 3.5, o instalador abortava e saía da instalação com erro. Tentei primeiro diversas coisas como: reiniciar o computador, limpar o registro, logar com um usuário local, fora da rede etc.
Comecei a descobrir a solução quando baixei um pacote de instalação do .Net 3.5 separado da instalação do Visual Studio.
Download do pacote completo de redistribuição do Framework .Net 3.5
http://download.microsoft.com/download/6/0/f/60fc5854-3cb8-4892-b6db-bd4f42510f28/dotnetfx35.exe
Pelo log do instalador, eu vi que o problema era em um componente chamado XPSEPSC que estava causando o erro. Eu descobri um link para baixar e instalar separadamente o tal componente problemático.
Instalador do XPSEPSC
http://www.download.windowsupdate.com/msdownload/update/v3-19990518/cabpool/xpsepsc-x86-en-us_f01c40d4ce7a451a51724bb2c44c164d063938e6.exe
Nesse momento eu vi uma mensagem de erro na instalação do XPSEPSC que me chamou a atenção. Alguma coisa dizendo que eu precisava de priviégios administrativos para continuar na instalação. Percebi então que o problema era de segurança e alguma norma do AD estava interferindo em minha instalação.
Nas pesquisas que fiz, descobri que este problema também se apresenta na forma de uma mensagem de erro que informa um termo "return value 3".
Para resolver, encontrei um pacote de ferramentas para administração e manutenção de servidores de forma remota. Chama PSTools. Nesse pacote tem uma ferramenta sensacional chamada PSExec.exe. Essa ferramenta faz uma impersonalização - se é que essa palavra existe - mas basicamente ela executa uma outra aplicação "por você" com identidade do usuário System, que é o usuário local com permissão total no Windows.
Instalador do PSTools
http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx
O PSTools é um pacote de aplicativos, e o que nos interessa é o PSExec. Copie-o no diretório do Windows para ficar mais fácil de usar, pois ele é utilizado via linha de comando.
Utilize o comando abaixo para executar o instalador do XPSEPSC, por exemplo:
psexec -s -i "c:\exemplo\XPSEPSC-x86-en-US.exe"
Sempre digite o caminho absoluto. O PSExec não funciona com paths relativos.
Outro detalhe. Não se assuste se o seu anti-virus detectar esse aplicativo como um vírus. O próprio autor comenta no site do link acima que esse programa já foi usado por vários vírus para efetuar suas ações maliciosas, mas ele em si não é um vírus.
Até a próxima!
Renato Graccula
Organizando a Casa
Bom, ainda estou planejando o rumo deste blog. Na verdade eu criei esse blog com o nome Biotronics, pois eu queria publicar tutoriais sobre eletrônica e tecnologias biométricas.
Agora estou estudando outras coisas e acho que não deveria deixar passar a oportunidade de publicar meus aprendizados aqui. Mais para frente, quem sabe eu não abra uma área sobre eletrônica.
Para falar a verdade eu já tenho dois tutoriais prontos, um que ensina a escrever frases em um LCD de duas linhas por dezesseis caracteres; o outro ensina a programar o firmware de um micro-controlador.
Mas isso fica para depois. Agora vou colocar no ar uns posts sobre a instalação e configuração de um ambiente para desenvolvimento baseado nas mais novas tecnologias e tendências do mercado.
Estou falando do Framework .Net 3.5, do ambiente de desenvolvimento (IDE - Integrated Development Environment) Visual Studio 2008, dos novos padrões de arquitetura de desenvolvimento (Design Patterns) e do servidor de base de dados (SGBD - Sistema de Gerenciamento de Banco de Dados) SQL Server 2008.
Tem alguns outros nomes complicados também, mas vamos parar por aqui. Agora vou criar um post para explicar problemas que enfrentei na instalação do Microsoft Framework .Net 3.5. Consegui achar uma solução para resolver o problema que acho interessante divulgar, pois consegui achar apenas dois posts em fóruns bem escondidos sobre o assunto.
Até a próxima!
Renato Graccula
Agora estou estudando outras coisas e acho que não deveria deixar passar a oportunidade de publicar meus aprendizados aqui. Mais para frente, quem sabe eu não abra uma área sobre eletrônica.
Para falar a verdade eu já tenho dois tutoriais prontos, um que ensina a escrever frases em um LCD de duas linhas por dezesseis caracteres; o outro ensina a programar o firmware de um micro-controlador.
Mas isso fica para depois. Agora vou colocar no ar uns posts sobre a instalação e configuração de um ambiente para desenvolvimento baseado nas mais novas tecnologias e tendências do mercado.
Estou falando do Framework .Net 3.5, do ambiente de desenvolvimento (IDE - Integrated Development Environment) Visual Studio 2008, dos novos padrões de arquitetura de desenvolvimento (Design Patterns) e do servidor de base de dados (SGBD - Sistema de Gerenciamento de Banco de Dados) SQL Server 2008.
Tem alguns outros nomes complicados também, mas vamos parar por aqui. Agora vou criar um post para explicar problemas que enfrentei na instalação do Microsoft Framework .Net 3.5. Consegui achar uma solução para resolver o problema que acho interessante divulgar, pois consegui achar apenas dois posts em fóruns bem escondidos sobre o assunto.
Até a próxima!
Renato Graccula
quinta-feira, 29 de janeiro de 2009
Quebra de Paradigma Tecnológico
Quem me conhece a bastante tempo sabe que eu fui o criador de um site de tecnologia chamado Serial Link.
Este site teve uma história longa – um dia eu conto aqui no blog – e no final, morreu. Acabou. O motivo é simples: o intuito do site era oferecer ensinamentos em programação – ASP e VB6 na época – de graça.
O material do site não possuía nenhum tipo de bloqueio contra cópia. O que aconteceu é que vários outros sites começaram a fazer links diretos para o meu site.
Resultado: o consumo de banda aumentou astronomicamente e conseqüentemente o valor do plano de hospedagem. Cheguei a pagar cerca de oitocentos reais em um determinado mês. Não consegui sustentar tal investimento.
Hoje, anos depois estou de volta. Fui reduzido a um blog. Começar de novo. Nunca foi um problema para mim.
Aconteceu exatamente agora na minha vida. Saí de um emprego que já estava durando cinco anos. Fiquei parado em uma plataforma tecnológica por longos cinco anos.
Acordei com um choque de tecnologia. Comecei a trabalhar essa semana com o Framework .Net 3.5, Visual Studio 2008, SQL Server 2005, Spring.Net, NHibernate, WCF, MyGeneration e Enterprise Architect.
Para quem estava trabalhando cinco longos anos com ASP, ASP.Net 1.1 e SQL Server 2000 é um choque e tanto!
Acordei em um mundo que não falava a minha língua! De repente me deparei com a inversão de controle... Quase deu um nó no meu cérebro. E não pára por aí, além da inversão de controle, a injeção de dependência, a programação orientada ao aspecto e aos serviços. Minha vista ficou até turva!
Agora estou estudando e entendendo algumas coisas. Vou postar minhas descobertas de desafios nos próximos posts desse blog.
Fiquem ligados, descobri coisas bem interessantes e que mudaram minha visão de tecnologia e de produção de sistemas empresariais.
Em breve vou começar a postar artigos sobre o que estou aprendendo. Apresentarei o meu ponto de vista sobre os assuntos citados acima.
Abraços,
Renato Graccula
Este site teve uma história longa – um dia eu conto aqui no blog – e no final, morreu. Acabou. O motivo é simples: o intuito do site era oferecer ensinamentos em programação – ASP e VB6 na época – de graça.
O material do site não possuía nenhum tipo de bloqueio contra cópia. O que aconteceu é que vários outros sites começaram a fazer links diretos para o meu site.
Resultado: o consumo de banda aumentou astronomicamente e conseqüentemente o valor do plano de hospedagem. Cheguei a pagar cerca de oitocentos reais em um determinado mês. Não consegui sustentar tal investimento.
Hoje, anos depois estou de volta. Fui reduzido a um blog. Começar de novo. Nunca foi um problema para mim.
Aconteceu exatamente agora na minha vida. Saí de um emprego que já estava durando cinco anos. Fiquei parado em uma plataforma tecnológica por longos cinco anos.
Acordei com um choque de tecnologia. Comecei a trabalhar essa semana com o Framework .Net 3.5, Visual Studio 2008, SQL Server 2005, Spring.Net, NHibernate, WCF, MyGeneration e Enterprise Architect.
Para quem estava trabalhando cinco longos anos com ASP, ASP.Net 1.1 e SQL Server 2000 é um choque e tanto!
Acordei em um mundo que não falava a minha língua! De repente me deparei com a inversão de controle... Quase deu um nó no meu cérebro. E não pára por aí, além da inversão de controle, a injeção de dependência, a programação orientada ao aspecto e aos serviços. Minha vista ficou até turva!
Agora estou estudando e entendendo algumas coisas. Vou postar minhas descobertas de desafios nos próximos posts desse blog.
Fiquem ligados, descobri coisas bem interessantes e que mudaram minha visão de tecnologia e de produção de sistemas empresariais.
Em breve vou começar a postar artigos sobre o que estou aprendendo. Apresentarei o meu ponto de vista sobre os assuntos citados acima.
Abraços,
Renato Graccula
Assinar:
Postagens (Atom)