Wow!!!
Quase dois meses já se passaram desde a última postagem. Parece que foi ontem... Neste período estive lendo e aprendendo a utilizar o C# (eh... decidi que a aplicação será em C#). Decidi também que irei criar um software cliente para as Estações de Trabalho com acesso central a um Servidor de Aplicações. Nada de comunicação direta com o Banco de Dados. Tudo passa pelo "Client Data Access" (ops... não era pra falar o nome do servidor :P).
Okay... Já tenho uma base razoável com o C# (classe, interface, instanciação, herança, abstração, poliformismo, coleções, serialização, ...), em resumo, o basicão. Ainda preciso aprofundar um pouco na Camada de Acesso a Dados. O System.Data ainda fala grego comigo.
Mas no momento, estou mais preocupado em fazer o software cliente conversar com o "Client Data Access". Tá na hora de aprofundar um pouco mais em aplicações distribuídas... entra em cena o Windows Communication Foundation ou WCF.
Bora botar a preguiça de lado e ler mais alguns livrinhos de (em média) 800 páginas.
Até o próximo post.
terça-feira, 30 de agosto de 2011
segunda-feira, 6 de junho de 2011
Diário Técnico - 06 de junho de 2011
Ha!
A V1 do Diagrama de Entidade-Relacionamento está pronta e o Bulk Load do arquivo XML está funcionando maravilhosamente bem. E, pra variar, foram feitas novas modificações e claro, novos dados estão sendo coletados. Só um pequeno peek: Estou coletando as ACEs dos compartilhamentos... O que isso significa?! Hum... Vejamos...... Backup dos compartilhamentos...? Documentação dos compartilhamentos...? Exportação dos compartilhamentos...? As opções são vastas!
Como disse no post anterior, tá na hora de arrumar a Salada de Frutas: Eu, particularmente, gosto de saber "o que está rolando na minha rede" e, para isso, crio um mecanismo que me informa todo e qualquer hardware ou software novo que aparece nos computadores. Convenhamos que, por mais Políticas de Segurança ou Restrições que são impostas aos usuários, sempre tem aquele espertinho ou "computador privilegiado" que instalam softwares por contra própria sem saber se podem ou não. Por isso, acho importante saber quando um software (digamos ainda não catalogado) aparece em algum computador da rede e por que não, criar um mecanismo para questionar o usuário o motivo da instalação daquele software? Imagina a cena: O usuário recebendo uma mensagem: "Favor, justifique o motivo da instalação do software tal neste computador:" Rá! Tenho certeza que ele ia ficar branco na hora :P Ainda mais se for um CS (Counter Strike) ou similar xD.
Ainda estou na dúvida se crio ou não um cliente para instalação nas estações de trabalho. Um esquema de execução remota seria mais fácil, mas poderia consumir muita banda; ao passo que um cliente em cada estação de trabalho abriria o leque para rotinas de monitoramento e menor tráfego de rede, mas daria um pouco mais de trabalho na questão de atualização dos clientes e abertura de portas no firewall. Vamos ver o que o futuro dirá.
No mais, bora conhecer o Visual Studio e escolher se aprendo VB ou C#. Cya!
A V1 do Diagrama de Entidade-Relacionamento está pronta e o Bulk Load do arquivo XML está funcionando maravilhosamente bem. E, pra variar, foram feitas novas modificações e claro, novos dados estão sendo coletados. Só um pequeno peek: Estou coletando as ACEs dos compartilhamentos... O que isso significa?! Hum... Vejamos...... Backup dos compartilhamentos...? Documentação dos compartilhamentos...? Exportação dos compartilhamentos...? As opções são vastas!
Como disse no post anterior, tá na hora de arrumar a Salada de Frutas: Eu, particularmente, gosto de saber "o que está rolando na minha rede" e, para isso, crio um mecanismo que me informa todo e qualquer hardware ou software novo que aparece nos computadores. Convenhamos que, por mais Políticas de Segurança ou Restrições que são impostas aos usuários, sempre tem aquele espertinho ou "computador privilegiado" que instalam softwares por contra própria sem saber se podem ou não. Por isso, acho importante saber quando um software (digamos ainda não catalogado) aparece em algum computador da rede e por que não, criar um mecanismo para questionar o usuário o motivo da instalação daquele software? Imagina a cena: O usuário recebendo uma mensagem: "Favor, justifique o motivo da instalação do software tal neste computador:" Rá! Tenho certeza que ele ia ficar branco na hora :P Ainda mais se for um CS (Counter Strike) ou similar xD.
Ainda estou na dúvida se crio ou não um cliente para instalação nas estações de trabalho. Um esquema de execução remota seria mais fácil, mas poderia consumir muita banda; ao passo que um cliente em cada estação de trabalho abriria o leque para rotinas de monitoramento e menor tráfego de rede, mas daria um pouco mais de trabalho na questão de atualização dos clientes e abertura de portas no firewall. Vamos ver o que o futuro dirá.
No mais, bora conhecer o Visual Studio e escolher se aprendo VB ou C#. Cya!
segunda-feira, 30 de maio de 2011
Diário Técnico - 30 de maio de 2011
Ler dados da CIMv2 é interessante... Mais interessante ainda é quando juntamos esses dados em um único ponto e podemos observar que o que fora feito para padronizar, possui uma certa despadronização. Vejamos:
- Coletei informações da placa mãe de um computador e encontrei o fabricante "Intel". Neste mesmíssimo computador, coletei informações do processador e encontrei o fabricante "GenuineIntel". Não é o mesmo fabricante?!
- Outra nóia da Intel é começar o nome do processador com diversos espaços em branco, ou seja, ao invés de ser "Intel Pentium ..." é " Intel Pentium...". Explica isso?!
Outra também bem legal:
- Coletei informações do disco rígido de um computador e no fabricante não vinha nada, mas no modelo estava "SAMSUNG HD500...". Assim fica difícil!!
Vou ter que organizar essa Salada de Frutas para ter algo mais apresentável dentro do Projeto. Este era um processo que já existia na minha antiga aplicação: Eu coletava as informações, submetia-as a uma triagem (isso dava um trabalho, mas o resultado valia o esforço), e só então armazenava os dados em uma estrutura que chamava de "Base Oficial". Tô vendo que não vou fugir desse processo.
Quanto mais exploro a CIMv2, mais idéias mirabolantes eu tenho. Já consigo coletar informações que antes nem imaginava e isso me fez pensar em novas funcionalidades para o Projeto como comparativo de configuração de rede ou até mesmo documentação da rede (até hoje, não conheço nenhum software que faça isso).
E tem também a parte de software. Essa eu ainda nem comecei a trabalhar, mas algumas idéias já começam a surgir. Coisas como política de uso interno do software ou associação ao contrato de licenciamento e por aí vai... Mas vou deixar esse cara para depois, o foco agora é o hardware.
O modelo de dados já está ficando bem complexo e com as normalizações de alguns campos, a coisa só aumenta. :P
Mas, não tenho pressa... Não tenho prazo de entrega do Projeto. xD
- Coletei informações da placa mãe de um computador e encontrei o fabricante "Intel". Neste mesmíssimo computador, coletei informações do processador e encontrei o fabricante "GenuineIntel". Não é o mesmo fabricante?!
- Outra nóia da Intel é começar o nome do processador com diversos espaços em branco, ou seja, ao invés de ser "Intel Pentium ..." é " Intel Pentium...". Explica isso?!
Outra também bem legal:
- Coletei informações do disco rígido de um computador e no fabricante não vinha nada, mas no modelo estava "SAMSUNG HD500...". Assim fica difícil!!
Vou ter que organizar essa Salada de Frutas para ter algo mais apresentável dentro do Projeto. Este era um processo que já existia na minha antiga aplicação: Eu coletava as informações, submetia-as a uma triagem (isso dava um trabalho, mas o resultado valia o esforço), e só então armazenava os dados em uma estrutura que chamava de "Base Oficial". Tô vendo que não vou fugir desse processo.
Quanto mais exploro a CIMv2, mais idéias mirabolantes eu tenho. Já consigo coletar informações que antes nem imaginava e isso me fez pensar em novas funcionalidades para o Projeto como comparativo de configuração de rede ou até mesmo documentação da rede (até hoje, não conheço nenhum software que faça isso).
E tem também a parte de software. Essa eu ainda nem comecei a trabalhar, mas algumas idéias já começam a surgir. Coisas como política de uso interno do software ou associação ao contrato de licenciamento e por aí vai... Mas vou deixar esse cara para depois, o foco agora é o hardware.
O modelo de dados já está ficando bem complexo e com as normalizações de alguns campos, a coisa só aumenta. :P
Mas, não tenho pressa... Não tenho prazo de entrega do Projeto. xD
segunda-feira, 23 de maio de 2011
Diário Técnico - 23 de maio de 2011
Dando sequência ao Projeto...
Meu conhecimento em SQL é muito básico. Eu antes usava o SQL Server apenas como armazenamento dos dados. Os cálculos e procedimentos eram todos feitos na minha antiga aplicação, ou seja, nada no servidor e tudo no cliente (noob). Como a minha intenção é ter um Banco de Dados mais dinâmico e auto-sustentável (de onde tirei isso?), hora de investir nas Triggers, Functions e Stored Procedures.
Acertei alguns dos atributos do Banco de Dados (agora sei a diferença entre char e nchar ^^). Mas muitos ainda permanecem como varchar(max), porque preciso coletar mais informações de mais computadores. Tive que revisar o Script de Coleta de Dados, pois eu estava crente que para cada computador havia apenas 1 dispositivo de som e em um dos computadores coletados apareceram 2 dispositivos. ¬¬
Estive analisando alguns dos dados já coletados e acho que vou trazer uma idéia do meu antigo projeto para este. Essa idéia eu chamei de "Modelo de Objetos". O Modelo de Objetos é um conceito para padronizar e centralizar a nomenclatura dos diversos componentes e elementos existentes no computador. Ao invés de ter diversas tabelas, uma para cada tipo de componente e cada qual com um campo para o nome do componente, eu utilizo um modelo comum que define o nome de qualquer tipo de componente. Seria uma forma de "normalização dos dados". Um Modelo de Objeto é composto por 6 elementos variáveis:
Meu conhecimento em SQL é muito básico. Eu antes usava o SQL Server apenas como armazenamento dos dados. Os cálculos e procedimentos eram todos feitos na minha antiga aplicação, ou seja, nada no servidor e tudo no cliente (noob). Como a minha intenção é ter um Banco de Dados mais dinâmico e auto-sustentável (de onde tirei isso?), hora de investir nas Triggers, Functions e Stored Procedures.
Acertei alguns dos atributos do Banco de Dados (agora sei a diferença entre char e nchar ^^). Mas muitos ainda permanecem como varchar(max), porque preciso coletar mais informações de mais computadores. Tive que revisar o Script de Coleta de Dados, pois eu estava crente que para cada computador havia apenas 1 dispositivo de som e em um dos computadores coletados apareceram 2 dispositivos. ¬¬
Estive analisando alguns dos dados já coletados e acho que vou trazer uma idéia do meu antigo projeto para este. Essa idéia eu chamei de "Modelo de Objetos". O Modelo de Objetos é um conceito para padronizar e centralizar a nomenclatura dos diversos componentes e elementos existentes no computador. Ao invés de ter diversas tabelas, uma para cada tipo de componente e cada qual com um campo para o nome do componente, eu utilizo um modelo comum que define o nome de qualquer tipo de componente. Seria uma forma de "normalização dos dados". Um Modelo de Objeto é composto por 6 elementos variáveis:
[Classe] + [Sub-Classe] + [Fabricante] + [Modelo] + [Valor] + [Medida]
- A classe define o que é o objeto: Processador, Placa Mãe, Disco Rígido, Impressora, etc.
- A sub-classe define uma categoria do objeto: IDE, PCI, Jato de Tinta, Laser, etc.
- O fabricante err... é o fabricante do objeto.
- O modelo... já entenderam, né?
- O valor seria um número relacionado ao modelo: a frequência de um processador, o tamanho de um disco rígido, a memória RAM de uma placa de vídeo, etc.
- A medida seria a unidade de medida do valor: GB, MB, MHz, GHz, etc.
Baseado neste Modelo de Objeto eu posso nomear qualquer componente do meu computador:
Processador Intel Pentium 4 3.0 GHz
Placa Mãe Asus P5KPL/1600
Disco Rígido SATA Samsung HD502HI 500 GB
Impressora Laser HP LaserJet 1015
Monitor LCD LG Flatron
Outra vantagem deste modelo está na pesquisa: Como está tudo centralizado, é mais fácil descobrir por exemplo, quais equipamentos de um determinado fabricante são mais utilizados entre os computadores analisados.
Essa etapa vai consumir um bom tempo. Já que quero um Banco de Dados mais autônomo, vou estudar mais sobre Triggers, Functions e Stored Procedures para deixar que o SQL Server faça aquilo que era feito pela aplicação.
Wish me luck!
quinta-feira, 19 de maio de 2011
Diário Técnico - 19 de maio de 2011
Hora de por a mão na massa!
Primeira etapa é a Coleta dos Dados. Minha intenção é fazer isso sem ter que instalar nada no Cliente. Tudo vai ficar por conta do Servidor. Tenho feito testes utilizando o WMI com o Powershell para a Coleta dos Dados e estou gostando muito do resultado. Vou seguir por esse caminho. Mais pra frente, talvez seja interessante eu olhar o WBEM e o SNMP para expandir a Coleta para outras plataformas. Mas prefiro ir devagar para não surtar antes. :P
O WMI tem informação pra ca**lho. Vou começar com algumas que acho importante e a medida que o projeto cresce vou agregando novos dados. Resolvi gerar um arquivo XML com os dados coletados. No meu antigo projeto eu gerava um arquivo INI. Quis mudar para conhecer o XML e achei muito mais prático. A visualização do arquivo XML no IE é muito mais amigável do que o antigo INI no bloco de notas (argh).
O Banco de Dados (lógico) será o SQL Server (sou MS addicted, esqueceram?). Criei umas tabelas para receber os dados coletados. O próximo passo é importar os dados do XML para o SQL Server.
Pesquisando na net achei um esquema chamado "SQL XML Bulk Load"... fantárdico!!! Depois de muito digitar, criei um arquivo XSD que relaciona os elementos do meu XML aos campos das tabelas que criei. E o cara ainda gera a chave primária e replica para as tabelas filho criando todo o relacionamento dinamicamente! (Yess)
So far.. so good! Até agora tudo fluindo bem. Hora de revisar os atributos das tabelas. Defini a maioria como varchar(max) só para testar o funcionamento do Bulk Load. Agora tá na hora de definir tudo bunitim...
Stay tuned for news!
Primeira etapa é a Coleta dos Dados. Minha intenção é fazer isso sem ter que instalar nada no Cliente. Tudo vai ficar por conta do Servidor. Tenho feito testes utilizando o WMI com o Powershell para a Coleta dos Dados e estou gostando muito do resultado. Vou seguir por esse caminho. Mais pra frente, talvez seja interessante eu olhar o WBEM e o SNMP para expandir a Coleta para outras plataformas. Mas prefiro ir devagar para não surtar antes. :P
O WMI tem informação pra ca**lho. Vou começar com algumas que acho importante e a medida que o projeto cresce vou agregando novos dados. Resolvi gerar um arquivo XML com os dados coletados. No meu antigo projeto eu gerava um arquivo INI. Quis mudar para conhecer o XML e achei muito mais prático. A visualização do arquivo XML no IE é muito mais amigável do que o antigo INI no bloco de notas (argh).
O Banco de Dados (lógico) será o SQL Server (sou MS addicted, esqueceram?). Criei umas tabelas para receber os dados coletados. O próximo passo é importar os dados do XML para o SQL Server.
Pesquisando na net achei um esquema chamado "SQL XML Bulk Load"... fantárdico!!! Depois de muito digitar, criei um arquivo XSD que relaciona os elementos do meu XML aos campos das tabelas que criei. E o cara ainda gera a chave primária e replica para as tabelas filho criando todo o relacionamento dinamicamente! (Yess)
So far.. so good! Até agora tudo fluindo bem. Hora de revisar os atributos das tabelas. Defini a maioria como varchar(max) só para testar o funcionamento do Bulk Load. Agora tá na hora de definir tudo bunitim...
Stay tuned for news!
Assinar:
Postagens (Atom)